Warn when downloading files over http and ftp

[msmeissn]

http: is no longer considered secure, can you disallow download_files from http and ftp urls?

same for ftp

Goal is for maintainers to switch to https URLs.

@jsegitz

[coolo]

IMO: That sounds like a policy to be coded elsewhere (rpmlint?). This is a download service not a policy checker

[dirkmueller]

Go for fixing it first:

git grep -E "Source.*(http|ftp)://" | wc -l
2913

[dirkmueller]

Also there are many open source components in our distro that are not available via https:// for example, so people would be removing the canonical url to fix the error instead, which is even counter productive for our Supply Chain Security project.

[dirkmueller]

also problematic (and not done via obs-source-download_files):

git grep -E "url.*git://" | grep -v Git-Clone | wc -l
271

[msmeissn]

my idea is having a WARN algorithm to have maintainers go look for https urls.

I know the state of the distribution, but i cant do this all myself.

[jsegitz]

I would also favor a warning to make packagers aware. Disallowing it fully will be inconvenient for ancient projects that don't offer anything.

As for rpmlint: First of all that's rather late. When this service is run (quite often directly by the maintainer) I think the chances are higher that he will take the chance to do the change. Also I'm not sure if this information even is in the resulting binary rpm.

[dirkmueller]

Thanks, I did not read "do not allow download files" as "warn user to search for an alternative" ;)

Also I'm not sure if this information even is in the resulting binary rpm.

it isn't, but rpmlint is also run on the src.rpm, where the information is fully available. I find download_files the wrong place any of the following reasons:

• no filtering possibility for the packager
• it is only run when the package is touched. usually we have those issues in packages that are not touched at all
• if the authenticity is done differently (for exampe gpg signature, or a sha256 as '#!RemoteAsset), the transport location does not matter that much anymore
• we're only validating those that have Sources, not patches or the like
• increasingly people are switching away from full tarball urls towards git references, so the check would have to be ported/reimplemted in all other services that provide assets as well

Instead I think this should be implemented as a repeating task (making sure that source links remain active and the content does not change over what we have cached) or as a rpmlint check, where the complete situation can be evaluated for a meaningful warning message.

Alternatively this could end up in spec-cleaner directly, so instead of warning, simply rewrite the urls. for example we know that ftp://ftp.gnu.org/ is available as https://ftp.gnu.org also.

[jsegitz]

Okay, I'm convinced :) I'll add this to our improvement topics and we'll explore the possibility to have that in rpmlint. That seems to be the logical place to me given the reasoning above