-
Notifications
You must be signed in to change notification settings - Fork 47
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
Don't require encoding for namespaced packages #420
Comments
@scovetta @gfs You might want to be careful before doing this. As I mentioned on #418, the Package URL spec expects Maybe instead we could improve the error messaging? E.g. if a given Package URL fails to parse, we could check for cases like this (e.g. the package URL looks like an npm package, with |
I think the reporting user makes a fair point that even if that is what the spec says it's not very intuitive. Particularly for handling perhaps manually typed input on a command line if we can reasonably detect this case where the @ for the namespace needs to be encoded why don't we just automatically do it on the users behalf? |
Actually, I think we deviate from the spec too a bit - in at least some cases, we require the slash separator between namespace and name to be encoded. This means we get namespace=
According to the spec, that |
@gfs That's not an unreasonable point. I can't think of any way that might go wrong - but that said, the types of subtle bugs that can result from tolerating deviations from specs tend to be hard to predict. If you go forward with that approach, would you mind keeping that tolerant parsing behavior at the CLI layer? For Terrapin (which consumes the Shared and oss-find-squats-lib libraries), strict compliance with spec is part of how we make sure subtle bugs in our system get surfaced while handling millions of distinct package versions. (I think those libraries primarly work with already-parsed Package URL objects so this point might be a non-issue - but I thought I would mention it just in case any part(s) of those libraries accepts package URLs as strings). |
Yes, I can keep it at the CLI layer. Makes sense to me.
…On Tue, May 16, 2023 at 10:35, Paul Malmsten ***@***.***(mailto:On Tue, May 16, 2023 at 10:35, Paul Malmsten <<a href=)> wrote:
> Particularly for handling perhaps manually typed input on a command line if we can reasonably detect this case where the @ for the namespace needs to be encoded why don't we just automatically do it on the users behalf?
***@***.***(https://github.com/gfs) That's not an unreasonable point. I can't think of any way that might go wrong - but that said, the types of subtle bugs that can result from tolerating deviations from specs tend to be hard to predict.
If you go forward with that approach, would you mind keeping that tolerant parsing behavior at the CLI layer? For Terrapin (which consumes the [Shared](https://github.com/microsoft/OSSGadget/tree/main/src/Shared) and [oss-find-squats-lib](https://github.com/microsoft/OSSGadget/tree/main/src/oss-find-squats-lib) libraries), strict compliance with spec is part of how we make sure subtle bugs in our system get surfaced while handling millions of distinct package versions. (I think those libraries primarly work with already-parsed Package URL objects so this point might be a non-issue - but I thought I would mention it just in case any part(s) of those libraries accepts package URLs as strings).
—
Reply to this email directly, [view it on GitHub](#420 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAAYEVE3HIJKH7YB4AVNWXLXGO3GXANCNFSM6AAAAAAYBPCERM).
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
In the oss-download CLI its inconvenient (and perhaps unintuitive) to the user to manually escape their @. If we detect an unescaped @ that is in the first character of a namespace component of the purl we can replace it with %40. Fix #420
#433) * Fix Npm Project Manager's Download Version Async respecting namespaces * Replace @ with %40 when provided in the namespace of a purl In the oss-download CLI its inconvenient (and perhaps unintuitive) to the user to manually escape their @. If we detect an unescaped @ that is in the first character of a namespace component of the purl we can replace it with %40. Fix #420 * Update DownloadTool.cs
Currently, we require namespaced packages to have the
@
and/
symbols encoded. I don't recall precisely why this was needed, but we should fix this so that you can just have, for example:Ref: #418
The text was updated successfully, but these errors were encountered: