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

registry/handles/app: always append default urls regexps #2035

Merged
merged 1 commit into from
Dec 6, 2016

Conversation

runcom
Copy link
Contributor

@runcom runcom commented Nov 2, 2016

Even when validation is off, we don't want to allow manifests with foreign layers urls.

Signed-off-by: Antonio Murdaca [email protected]

@codecov-io
Copy link

codecov-io commented Nov 2, 2016

Current coverage is 51.10% (diff: 100%)

Merging #2035 into master will decrease coverage by 8.72%

@@             master      #2035   diff @@
==========================================
  Files           128        128           
  Lines         11402      11404      +2   
  Methods           0          0           
  Messages          0          0           
  Branches          0          0           
==========================================
- Hits           6822       5828    -994   
- Misses         3714       4825   +1111   
+ Partials        866        751    -115   

Powered by Codecov. Last update 314144a...0fb25dd

@aaronlehmann
Copy link
Contributor

Hi @runcom - I feel like I'm missing some context here. Why should foreign layer URLs be prohibited when validation is disabled? It seems a bit counter-intuitive.

@runcom
Copy link
Contributor Author

runcom commented Nov 3, 2016

Hi @runcom - I feel like I'm missing some context here. Why should foreign layer URLs be prohibited when validation is disabled? It seems a bit counter-intuitive.

I know, but we didn't want default installation to allow layers urls, did we?

@aaronlehmann
Copy link
Contributor

I wonder why validation is not enabled by default.

@runcom
Copy link
Contributor Author

runcom commented Nov 3, 2016

I wonder why validation is not enabled by default.

I don't have any clue, great question.

@runcom
Copy link
Contributor Author

runcom commented Nov 30, 2016

I wonder why validation is not enabled by default.

does anyone have any idea on @aaronlehmann thought?

@dmcgowan
Copy link
Collaborator

dmcgowan commented Nov 30, 2016

So this change is effectively changing the default behavior from support ".*" in the URLs to support "$^", not sure if anyone would be effected by this. This would also mean if you want ".*" for some reason, you should have to configure it using validation.

I know, but we didn't want default installation to allow layers urls, did we?

I also don't know if this was an intentional decision, can ping @stevvooe as well. Either way let's make that decision now. I think I agree that it is better to be more restrictive by default with foreign URLs since it has the potential for malicious use.

@@ -244,6 +244,8 @@ func NewApp(ctx context.Context, config *configuration.Configuration) *App {
options = append(options, storage.ManifestURLsDenyRegexp(re))
}
}
} else {
options = append(options, storage.ManifestURLsAllowRegexp(regexp.MustCompile("^$")))
Copy link
Collaborator

Choose a reason for hiding this comment

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

Didn't realize we just plopped all this in the middle of a function. Sigh.

Copy link
Contributor Author

@runcom runcom Nov 30, 2016

Choose a reason for hiding this comment

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

Can we refactor this later but at least agree on whether we should make this change or not....

Copy link
Collaborator

Choose a reason for hiding this comment

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

@runcom I'm just lamenting. Let's not make big changes in this PR.

@stevvooe
Copy link
Collaborator

@dmcgowan @runcom The backwards compatibility policy would dictate that we continue to be relaxed about extra fields.

Let's introduce a Validation.Disabled field, which should be favored over Validation.Enabled and transition this to the default:

if !Validation.Enabled {
  Validation.Enabled = !Validation.Disabled
}

if Validation.Enabled {
 // default validation, with or without entries
} else {
  // no validation
}

There may be a way to simplify that...

@runcom
Copy link
Contributor Author

runcom commented Dec 1, 2016

@dmcgowan @aaronlehmann @stevvooe PTAL

@@ -190,6 +190,8 @@ type Configuration struct {
Validation struct {
// Enabled enables the other options in this section.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Add a deprecated note here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

fixed

@stevvooe
Copy link
Collaborator

stevvooe commented Dec 2, 2016

LGTM

May need more to let people know about the deprecation.

@dmcgowan
Copy link
Collaborator

dmcgowan commented Dec 5, 2016

LGTM

Could we add note in the ### Disabled doc section about it deprecating enabled?

@runcom
Copy link
Contributor Author

runcom commented Dec 5, 2016

@dmcgowan updated

@runcom
Copy link
Contributor Author

runcom commented Dec 6, 2016

is this ready to go?

@dmcgowan dmcgowan merged commit 67095fb into distribution:master Dec 6, 2016
@runcom runcom deleted the fix-foreign-urls-check branch December 6, 2016 18:22
@dmcgowan
Copy link
Collaborator

Note for 2.7 change list,
Existing configurations configuration which had set Enabled: false will need to be updated to do Disabled: true to keep the validation disabled. This needs to be put in the upgrade notes

@stanhu
Copy link
Contributor

stanhu commented Jan 3, 2019

I just saw this issue after creating #2795.
This was confusing because our configuration had omitted enabled from the config, which I had erroneously assumed was on by default. We added disabled, and all was well again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants