Around 200 packages [0] include upstream scripts that download code via (non-secure) http, then run it without an integrity check.
This is obviously a security hole (network MITM => code execution), but
not necessarily one that is opened by normal use of the package. (E.g. fetch-dependencies-and-build scripts can't download anything on a Debian buildd, though it would still make sense to report them to upstream.)
Some instances of this (i.e. where the download origin offers it) are trivially improvable by replacing http with https.
How should this be dealt with?
- Mass report?
 - As BTS bugs (i.e. public) or private email?
- (imperfect) Lintian check based on [0]?
- If one is fixed, should it also be fixed in stable? (Probably depends
on how likely the script is to be used from the package)
Previous discussions that I can find [1-2] reached no clear conclusion, possibly because there were other issues involved (the trustworthiness
of the downloads' intended origin, and whether downloaders had to be in contrib).
[0] codesearch (wget|curl).*http://[^ ]*/[^ ]*\.(pl|sh|py|gz|xz|bz2|zip)($|[^a-z]) matches 368 packages, but not all
of them are actual security problems
[1] https://lists.debian.org/debian-security/2012/12/msg00030.html
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=449497
https isn´t any more secure than http as long as you do not have a verifiably trustworthy server certificate that you can check for. As we
know the certification authority system is totally broken.
It is a bug
if a build script tries to download something.
I do not see any way than to rewrite these build scripts and pack
all the necessary sources into the package for compiling it offline.
This is already policy (and enforced by blocking network access) for
official Debian package builds: dependencies must be installed by the
package manager, not the build script.
Around 200 packages [0] include upstream scripts that download code via (non-secure) http, then run it without an integrity check.
How should this be dealt with?
- (imperfect) Lintian check based on [0]?
On 01/05/2020 20:31, Elmar Stellnberger wrote:
https isn´t any more secure than http as long as you do not have a
verifiably trustworthy server certificate that you can check for. As
we know the certification authority system is totally broken.
Imperfect yes, but still better than nothing.
Not all the software that implement HTTPS verify the validity of the certificate and the validity of all the certification chain.These scripts are using wget or curl, which both say they do verify certificates. If they do not do so correctly, please report this.
For example where I work has been invalidated a certificate, but for mistake the new valid one was not loaded on a https site. With Debian and Firefox I cannot access that site (I get "the certificate is not valid" or something similar), but otherpeople, that use another OS, can access it with internet explorer and chrome, but not with Firefox.
On Fri, May 1, 2020 at 8:18 PM Rebecca N. Palmer wrote:
This is already policy (and enforced by blocking network access) for
official Debian package builds: dependencies must be installed by the
package manager, not the build script.
Correction: the debian.org buildds do not at this time block any
network access. The main issue is that schroot does not support it and
it has been orphaned and unmaintained for years. You might be thinking
of pbuilder, which does do this by default.
On 01/05/20 22:00, Rebecca N. Palmer wrote:
On 01/05/2020 20:31, Elmar Stellnberger wrote:
https isn´t any more secure than http as long as you do not have a
verifiably trustworthy server certificate that you can check for. As
we know the certification authority system is totally broken.
Imperfect yes, but still better than nothing.
There is another problem: implementation. Not all the software that
implement HTTPS verify the validity of the certificate and the
validity of all the certification chain.
For example where I work has been invalidated a certificate, but for
mistake the new valid one was not loaded on a https site.
and Firefox I cannot access that site (I get "the certificate is not
valid" or something similar), but other people, that use another OS,
can access it with internet explorer and chrome, but not with Firefox.
Ciao
Davide
It's better than nothing. Even if somebody were using self signed certificates that aren't publicly trusted, the information would still
be encrypted in transit. Whether the other end is trustworthy is
another issue and up to the user and package maintainers to decide,
but it would, at the very least, make it more difficult for a third
party to manipulate the information between the intended endpoints.
Am 02.05.2020 10:14, schrieb Davide Prina:
On 01/05/20 22:00, Rebecca N. Palmer wrote:
On 01/05/2020 20:31, Elmar Stellnberger wrote:
https isn´t any more secure than http as long as you do not have a verifiably trustworthy server certificate that you can check for. As
we know the certification authority system is totally broken.
Imperfect yes, but still better than nothing.
There is another problem: implementation. Not all the software that implement HTTPS verify the validity of the certificate and the
validity of all the certification chain.
For example where I work has been invalidated a certificate, but for mistake the new valid one was not loaded on a https site.
What do you mean by loaded on a https site? That the web server of the
site uses the certificate? Wasn´t there a CA for the new site?
With Debian
and Firefox I cannot access that site (I get "the certificate is not
valid" or something similar), but other people, that use another OS,
can access it with internet explorer and chrome, but not with Firefox.
Ciao
Davide
I've seen this before with Firefox. Basically Firefox has disabled
weaker certificates from
working, where Chrome and IE still accept ones with 128bit encryption,
they do show an error (at
least in Chrome) if you dig into the SSL debug screen. Firefox just
refuses to view it.
On 01/05/20 22:00, Rebecca N. Palmer wrote:
On 01/05/2020 20:31, Elmar Stellnberger wrote:
https isn´t any more secure than http as long as you do not have a
verifiably trustworthy server certificate that you can check for. As
we know the certification authority system is totally broken.
Imperfect yes, but still better than nothing.
There is another problem: implementation. Not all the software that implement HTTPS verify the validity of the certificate and the validity
of all the certification chain.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 293 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 239:15:36 |
| Calls: | 6,624 |
| Files: | 12,172 |
| Messages: | 5,319,991 |