Fix vulnerability that leaks private labels and milestones
This fixes vulnerability that leaks information about private labels and milestones because of insecure direct object reference in issueable create service.
This affects merge requests and issues.
See https://gitlab.com/gitlab-org/gitlab-ce/issues/15439
This MR introduces additional check that rejects labels and milestone that does not belong to the same project issue/merg request does.
`IssuableBaseService` may benefit from encapsulating filters in separate class/module, which then may improve coherency in this class.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/15439
See merge request !1954
Signed-off-by: Rémy Coutable <remy@rymai.me>
Optimize LDAP and add a search timeout
Related to #4282
This merge request arranges some things in `access.rb` to facilitate some optimizations in EE (to come later). It also adds a 10 second timeout to all LDAP searches so the entire worker is not blocked if some query doesn't return in a reasonable amount of time. This timeout is configurable per LDAP server.
See merge request !2267
Fix Error 500 when visiting build page of project with nil runners_token
Properly ensure that the token exists and add defensively check for a
non-nil value.
Closes#4294
See merge request !2294
Do not call API if there is no API URL
Fixes#5878
CE users may not be interested in the new JIRA features. In this case,
we should detect they haven't set an API URL and fallback to the
behavior pre-8.3. This patch does that very easily.
There are planned improvements to JIRA in future releases such as
gitlab-org/gitlab-ce#5541 which will make this more configurable.
See merge request !2341
Suppress e-mails on failed builds if allow_failure is set
Every time I push to GitLab, I get > 2 emails saying a spec failed when I don't care about the benchmarks and others that have `allow_failure` set to `true`.
@ayufan mentioned creating a summary e-mail to prevent getting one e-mail per build, but the latter might actually be desirable. For example, I do want to know if Rubocop errors fail right away.
See merge request !2178
Get "Merge when build succeeds" to work when commits were pushed to MR
target branch while builds were running
The Merge when build succeeds service only merges when the MR is
mergeable (open, not WIP, no conflicts).
When the target branch is updated, all affected MRs have their merge
status set to `unchecked`, and the conflicts check will only happen
when `check_if_can_be_merged` is called, which happens when the MR page
is viewed.
When someone enables the automatic merge, the target branch is updated,
no-one views the MR page again, and the build succeeds, the mergeability
check will fail and the MR will not in fact be merged.
This MR makes sure `check_if_can_be_merged` is always called when MR
mergeability is checked.
See merge request !2304
Robert Speicher
Robert SpeicherandRobert Speicher
Grzegorz BizonandRémy Coutable
Rémy CoutableandRémy Coutable
Stan HuandRobert Speicher
Douwe Maan
Jacob Vosmaer
Douwe MaanandRobert Speicher
Dmitriy ZaporozhetsandRobert Speicher
Douwe Maan
Jason Lee