- 31 Jan, 2019 40 commits
-
-
GitLab Bot authored
-
Yorick Peterse authored
This got merged up somewhere in the process of merging dev.gitlab.org and GitLab.com back together.
-
Yorick Peterse authored
-
GitLab Bot authored
-
GitLab Release Tools Bot authored
[ci skip]
-
Yorick Peterse authored
In commit 6fa5fd85 the `require: false` was removed to ensure the Gem was loaded at run time. Unfortunately, the `require` necessary for the rubyzip Gem is "zip" and not "rubyzip". As a result, Bundler would not require the Gem. This meant that we would still run into constant errors when referring to `Zip::File`.
-
GitLab Release Tools Bot authored
[ci skip]
-
Stan Hu authored
pages:deploy step was failing with the following error: ``` unitialized constant SafeZip::Extract::Zip ``` Since license_finder already pulls in rubyzip, we can make it a required gem. We also use the scope operator to make the reference to Zip::File explicit.
-
GitLab Release Tools Bot authored
[ci skip]
-
GitLab Release Tools Bot authored
[ci skip]
-
Douglas Barbosa Alexandre authored
Fix a JS race in a spec Closes #56860 See merge request gitlab-org/gitlab-ce!24684
-
Kamil Trzciński authored
-
Francisco Javier López authored
-
James Lopez authored
-
Constance Okoghenun authored
-
Nick Thomas authored
-
James Lopez authored
-
Steve Azzopardi authored
When a user is a guest user, and the "Public Pipeline" is set to false inside of "Settings > CI/CD > General" the commit status in the project dashboard should not be shown.
-
Jan Provaznik authored
When moving a project, it's possible that some users who had access to the project in old path can not access the project in the new path. Because `project_authorizations` records are updated asynchronously, when we send the notification about moved project the list of project team members contains old project members, we want to notify all these members except the old users who can not access the new location.
-
Dennis Tang authored
-
Stan Hu authored
To prevent an OAuth2 covert redirect vulnerability, this commit adds and uses an alias for the GitHub and BitBucket OAuth2 callback URLs to the following paths: GitHub: /users/auth/-/import/github Bitbucket: /users/auth/-/import/bitbucket This allows admins to put a more restrictive callback URL in the OAuth2 configuration settings. Instead of https://example.com, admins can now use: https://example.com/users/auth It's possible but not trivial to change Devise and OmniAuth to use a different prefix for callback URLs instead of /users/auth. For now, aliasing the import URLs under the /users/auth namespace should suffice. Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/56663
-
Nick Thomas authored
LFS uploads are handled in concert by workhorse and rails. In normal use, workhorse: * Authorizes the request with rails (upload_authorize) * Handles the upload of the file to a tempfile - disk or object storage * Validates the file size and contents * Hands off to rails to complete the upload (upload_finalize) In `upload_finalize`, the LFS object is linked to the project. As LFS objects are deduplicated across all projects, it may already exist. If not, the temporary file is copied to the correct place, and will be used by all future LFS objects with the same OID. Workhorse uses the Content-Type of the request to decide to follow this routine, as the URLs are ambiguous. If the Content-Type is anything but "application/octet-stream", the request is proxied directly to rails, on the assumption that this is a normal file edit request. If it's an actual LFS request with a different content-type, however, it is routed to the Rails `upload_finalize` action, which treats it as an LFS upload just as it would a workhorse-modified request. The outcome is that users can upload LFS objects that don't match the declared size or OID. They can also create links to LFS objects they don't really own, allowing them to read the contents of files if they know just the size or OID. We can close this hole by requiring requests to `upload_finalize` to be sourced from Workhorse. The mechanism to do this already exists.
-
Kamil Trzciński authored
RubyZip allows us to perform strong validation of expanded paths where we do extract file. We introduce the following additional checks to extract routines: 1. None of path components can be symlinked, 2. We drop privileges support for directories, 3. Symlink source needs to point within the target directory, like `public/`, 4. The symlink source needs to exist ahead of time.
-
Kushal Pandya authored
-
Kushal Pandya authored
-
Heinrich Lee Yu authored
This changes the permission check so it uses the policy on Noteable instead of Project. This prevents bypassing of rules defined in Noteable for locked discussions and confidential issues. Also rechecks permissions when reply_to_discussion_id is provided since the discussion_id may be from a different noteable.
-
Kushal Pandya authored
-
Brett Walker authored
Since we needed to bump the version to 13 in the backports, and we know that an MR on master also bumped it to 13, bump to 14 to ensure that when a customer upgrades to the most recent release, the markdown gets recalcuated as necessary.
-
Brett Walker authored
Such as those with IDN homographs or embedded right-to-left (RTLO) characters. Autolinked hrefs should be escaped
-
Francisco Javier López authored
-
Tiago Botelho authored
Group guests will only be displayed merge requests to projects they have a access level to, higher than Reporter. Visible projects will still display the merge requests to Guests
-
Francisco Javier López authored
When the external wiki is enabled, the internal wiki link is replaced by the external wiki url. But the internal wiki is still accessible. In this change the external wiki will have its own tab in the sidebar and only if the services are disabled the tab (and access rights) will not be displayed.
-
Luke Duncalfe authored
Fixes #54721
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Heinrich Lee Yu authored
When the parent noteable is not visible to the user (e.g. confidential) we prevent the user from adding emoji reactions to notes
-
Luke Duncalfe authored
-