Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add black list and white list support for migrating repositories #8040

Closed
wants to merge 5 commits into from

Conversation

lunny
Copy link
Member

@lunny lunny commented Aug 30, 2019

This PR will add two options blacklist and whitelist for migrating repositories from external URLs.

When you set whitelist then blacklist will be ignored and all users on this gitea instance could only migrate repositories from the domains on whitelist.

When whitelist is empty and you have domains on blacklist, all users on this gitea instance could migrate repositories any domain except the domains on blacklist.

@lunny lunny added the type/enhancement An improvement of existing functionality label Aug 30, 2019
@lunny lunny added this to the 1.10.0 milestone Aug 30, 2019
WHITELISTED_DOMAINS =
; Blacklist for migrating, default is blank. Multiple domains could be separated by commas.
; When WHITELISTED_DOMAINS is not blank, this option will be ignored.
BLACKLISTED_DOMAINS =
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing EOL

return false, err
}

if strings.EqualFold(u.Scheme, "http") || strings.EqualFold(u.Scheme, "https") {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why check the protocol? This will let ftp:, git: and ssh: pass if one day they are supported. Perhaps it's better to check if the url is local and make any other protocol go through whitelisting/blacklisting.

if strings.EqualFold(u.Scheme, "http") || strings.EqualFold(u.Scheme, "https") {
if len(setting.Migration.WhitelistedDomains) > 0 {
if !whitelist.Match(u.Host) {
return false, fmt.Errorf("Migrate from %v is not allowed", u.Host)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps a translatable error should be better?

var err error
whitelist, err = matchlist.NewMatchlist(setting.Migration.WhitelistedDomains...)
if err != nil {
return fmt.Errorf("Init migration whitelist domains failed: %v", err)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This error will show up when the instance starts, right? I mean, the admin needs to see the errors as soon as possible.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. It will display when gitea start.

@GiteaBot GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Aug 30, 2019
@guillep2k
Copy link
Member

A new rebase + make fmt to pick up the latest changes?

@lunny lunny force-pushed the lunny/black_list_migrate_mirror branch from 63a2947 to cdff51c Compare September 11, 2019 14:52
@codecov-io
Copy link

Codecov Report

Merging #8040 into master will increase coverage by <.01%.
The diff coverage is 48.27%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #8040      +/-   ##
==========================================
+ Coverage   41.81%   41.81%   +<.01%     
==========================================
  Files         482      484       +2     
  Lines       64557    64615      +58     
==========================================
+ Hits        26993    27018      +25     
- Misses      34095    34121      +26     
- Partials     3469     3476       +7
Impacted Files Coverage Δ
modules/setting/migrate.go 0% <0%> (ø)
routers/init.go 65.78% <25%> (-2.27%) ⬇️
modules/matchlist/matchlist.go 47.36% <47.36%> (ø)
modules/migrations/migrate.go 27% <60%> (+5.82%) ⬆️
models/unit.go 62.16% <0%> (-5.41%) ⬇️
modules/process/manager.go 76.81% <0%> (-4.35%) ⬇️
models/repo_list.go 74.14% <0%> (+0.97%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3fd0eec...cdff51c. Read the comment docs.

@lunny
Copy link
Member Author

lunny commented Sep 11, 2019

@guillep2k done.

}

for _, rule := range list.rules {
rg, err := glob.Compile(rule)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
rg, err := glob.Compile(rule)
rg, err := glob.Compile(rule,[]string{".","/"})

I think that separators should work better if specified, so the tokenization is aware of the different parts of the glob.

}

for _, rule := range list.rules {
rg, err := glob.Compile(rule)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some case normalization should be used. For instance, if I black list: "google.com", someone could work around that by using "GOOGLE.COM".

@guillep2k
Copy link
Member

guillep2k commented Sep 11, 2019

Thinking about it, I can set up a DNS of mine pointing to whatever site I want and make it work around the domain blacklist.

For example, the administrator wants to blacklist google.com (currently 172.217.30.238 for me); if I have access to a subdomain (e.g. myuser.dyndns.org), I could set up that to point to 172.217.30.238. Gitea wouldn't know anything about my setup, so I can import from myuser.dyndns.org (actually google.com) freely.

This is not easy to do, but we should be aware of the limitations of this kind of black list.
I think white list is much safer.

EDIT: rewording for clarity

I know domain aliasing is not an easy problem to solve for the blacklist functionality, but we should at least know that there's such vulnerability.
The whitelist part of this PR is OK from the safety point of view.

@lafriks
Copy link
Member

lafriks commented Sep 11, 2019

@guillep2k in this PR there is also support for whitelist

@guillep2k
Copy link
Member

@guillep2k in this PR there is also support for whitelist

@lafriks Yes. The whitelist part is OK. The blacklist part has some holes, as noted above. I think they require some rework.

@lunny lunny modified the milestones: 1.10.0, 1.11.0 Sep 25, 2019
@stale
Copy link

stale bot commented Nov 24, 2019

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 months. Thank you for your contributions.

@stale stale bot added the issue/stale label Nov 24, 2019
@lunny lunny added the issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented label Nov 24, 2019
@stale stale bot removed the issue/stale label Nov 24, 2019
@lunny lunny modified the milestones: 1.11.0, 1.12.0 Dec 13, 2019
@aschrijver
Copy link

aschrijver commented Feb 27, 2020

I maintain awesome-humane-tech and was advised to use ‘blocklist’ and ‘allowlist’ terminology instead (from a better inclusion / diversity perspective), and I wonder whether that would be better here too.

From WikiDiff:

blacklist: (legal) a list or collection of people or entities to be shunned or banned.

blocklist: (computing) a list of websites or other material to be blocked.

(and see also: http://garysaid.com/are-the-terms-whitelist-and-blacklist-racist/ )

Edit: See also IETF Recommendation (draft)

@lunny lunny modified the milestones: 1.12.0, 1.13.0 May 2, 2020
@lunny lunny modified the milestones: 1.13.0, 1.14.0 Sep 1, 2020
@6543
Copy link
Member

6543 commented Nov 16, 2020

@lunny do you work on this or should I catch it up?

@lunny
Copy link
Member Author

lunny commented Nov 17, 2020

@6543 Please pick it up.

@6543
Copy link
Member

6543 commented Nov 17, 2020

follow up pull: #13610

@6543 6543 closed this Nov 17, 2020
@lunny lunny deleted the lunny/black_list_migrate_mirror branch November 18, 2020 03:41
@lunny lunny removed this from the 1.14.0 milestone Nov 18, 2020
@aschrijver
Copy link

Thank you for switching terminology, much appreciated 🙏

@go-gitea go-gitea locked and limited conversation to collaborators Jan 18, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. type/enhancement An improvement of existing functionality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants