1. 31
  1.  

  2. 7

    Is this a proposal, or have they adopted this already? Signify/minisign is so much better than multi-purpose tools PGP/GPG. I hope they get this done ASAP.

    1. 4

      I think that’s an early specification, it even mentions “Rough Draft” at the end.

      That being said, it also covers cohabitation between the 2 which would help with a smoother transition and hopefully faster implementation and adoption.

    2. 3

      I believe Debian is one of the last bastions of the web of trust. Seems like it might fall soon. Somewhat sad to see it go.

      1. 1

        While I can see that this may give such an impression at a quick glance, it’s only about package verification performed by apt. Debain maintainers and uploaders will still use OpenPGP to authenticate their artifacts. It is far from Debian abandoning OpenPGP or their set of trusted keys.

        1. 1

          Just to play devil’s advocate isn’t Debian slowly moving on replacing OpenPGP usage with their own schemes? E.g. key endorsements instead of the Web of Trust.

      2. 2

        When do all their mirrors support https? Downloading something over http or even ftp does not feel like 2021.

        1. 12

          If they do this right (signed packages and so on), then https will only help with privacy. Which is important for sure, but leaking which packages you download is less horrible than leaking the contents of your conversations, or even just who you’ve been in contact with lately.

          1. -1

            HTTPS is more than just privacy. It also prevents JavaScript injection via ISPs, or any other MITM.

            1. 21

              It does that for web pages, not for packages. Packages are signed by the distro’s keys, so if anyone were to mess with your packages as you download them, your package manager would notice and prevent you from installing the package. The only real advantage to HTTPS for package distribution is that it helps conceal which packages you download (though even then, I get an attacker could get a pretty good idea just by seeing which server you’re downloading from and how many bytes you’re downloading).

              1. 1

                It does that for web pages, not for packages

                Indeed, however ISOs, USB installers, etc. can still downloaded from the web site.

                Packages are signed by the distro’s keys, so if anyone were to mess with your packages as you download them, your package manager would notice and prevent you from installing the package.

                Yes, I’m familiar with cryptographic signatures.

                1. 9

                  Indeed, however ISOs, USB installers, etc. can still downloaded from the web site.

                  Yes. The Debian website uses HTTPS, and it looks like the images are distributed using HTTPS too. I thought we were talking bout distributing packages using HTTP vs HTTPS. If your only point is that the ISOs should be distributed over HTTPS then of course I agree, and the Debian project seems to as well.

                  1. 0

                    No, the point is that there is no need for HTTP when HTTPS is available. Regardless of traffic, all HTTP should redirect to HTTPS IMNSHO.

                    1. 16

                      But… why? Your argument for why HTTPS is better is that it prevents JavaScript injection and other forms of MITM. But MITM clearly isn’t a problem for package distribution. Is your argument that “HTTPS protects websites against MITM so packages should use HTTPS (even thought HTTPS doesn’t do anything to protect packages from MITM)”?

                      I truly don’t understand what your reasoning is. Would you be happier if apt used a custom TCP-based transport protocol instead of HTTP?

                      1. 6

                        I suspect that a big reason is cost.

                        Debian mirrors will be serving an absurd amount of traffic, and will probably want to serve data as close to wire speed as possible (likely 10G). Adding a layer of TLS on top means you need to spend money on a powerful CPU or accelerator kit, instead of (mostly) shipping bytes from the disk to the network card.

                        Debian won’t be made of money, and sponsors won’t want to spend more than they absolutely have to.

                        1. 4

                          But MITM clearly isn’t a problem for package distribution.

                          It is though! Package managers still accept untrusted input data and usually do some parsing on it. apt has had vulnerabilities and pacman as well.

                          https://justi.cz/security/2019/01/22/apt-rce.html

                          https://xn--1xa.duncano.de/pacman-CVE-2019-18182-CVE-2019-18183.html

                          TLS would not prevent malicious mirrors in either of these cases, but it would prevent MITM attacks exploiting these issues.

                          1. 7

                            Adding TLS implementations also bring bugs, including RCE. And Debian is using GnuTLS for apt.

                            1. 1

                              Idd. It was one of the reasons for OpenBSD to create signify so I’m delighted to see Debians new approach might be based on it.

                              From https://www.openbsd.org/papers/bsdcan-signify.html:

                              … And if not CAs, then why use TLS? It takes more code for a TLS client just to negotiate hello than in all of signify.

                              The first most likely option we might consider is PGP or GPG. I hear other operating systems do so. The concerns I had using an existing tool were complexity, quality, and complexity.

                    2. 7

                      @sandro originally said: “When do all their mirrors support https?” Emphasis on “mirrors”. To the best of my knowledge, “mirror” in this context does not refer to a web site, or a copy thereof, but to a packages repository.

                      I responded specifically in this context. I was not talking about web sites, which rely on the transport mechanism for all security. In the context I was responding to, each package is signed. Your talk of JavaScript injection and other MITM attacks is simply off topic.

              2. 9

                ftp.XX.debian.org are CNAMEs to servers accepting to host a mirror. These servers are handled by unrelated organisations, so it is not possible to provide a proper cert for them. This match the level of trust: mirrors are not trusted with the content nor the privacy. This is not the case of deb.debian.org which is available over HTTPS if you want (ftp.debian.org is an alias for it).

                1. 2

                  Off line mirrors, people without direct internet access, decades later offline archives, people in the future, local DVD sets.

                  Why “trust” silent media?