Re: AW: AW: AW: Users GnuPG aims for? (Re: Breaking MIME concatenation)
On Fri 2018-05-18 05:31:36 +, Fiedler Roman wrote: > I see. If understood correctly, the trusted.gpg.d bypasses key > management with apt-key completely, so not running into problems with > apt-key deprecation. I'm actually advocating avoiding trusted.gpg.d entirely as well, and moving to explicit per-repo keyrings. So keep trusted.gpg and trusted.gpg.d completely empty, and populate /etc/apt/sources.list with lines like: deb [signed-by=/usr/share/keyrings/debian-archive-keyring.gpg] http://ftp.debian.org/debian buster main > I thought about that also, but shouldn't 99%+ of systems perform no > pinning whatsoever of packages to repositories? In that case, the > "wrong" repository could publish just a slightly increased package > version number of a package from another repository. You're asking the right questions. But please read https://wiki.debian.org/DebianRepository/UseThirdParty#Standard_pinning and the other sections on that page in more detail for the answers :) > Unless my system is misconfigured or other assumptions do not hold > true, that would imply, that the only security benefit from key > pinning is only about maintenance, making detection/pruning of stale > keys easier. Another benefit is that it is a necessary prerequisite if we want to be able to constrain some .debs (e.g. https://wiki.debian.org/UntrustedDebs and https://wiki.debian.org/Teams/Dpkg/Spec/DeclarativePackaging) based on their origin. This is still more work to be done, but if we can't isolate repos from one another than it'll never work. So please don't discount this work just because we haven't achieved all the rest of the isolation yet. The journey of a thousand miles begins with a single step, as they say. --dkg ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AW: AW: AW: Users GnuPG aims for? (Re: Breaking MIME concatenation)
Il 18/05/2018 07:31, Fiedler Roman ha scritto: > I thought about that also, but shouldn't 99%+ of systems perform no pinning > whatsoever of packages to repositories? In that case, the "wrong" repository > could publish just a slightly increased package version number of a package > from another repository. Unattended updates will apply it anyway and also for > users it would be hard noticing it: at least my "apt-get" version does not > show any information about the repository a package would be downloaded from > before confirming the installation. Thus the user would have to check each > single package manually by invoking "apt-cache policy [pkg-name]" or use > "apt-get download [packagelist]", check the logs and install packages with > "dpkg". Well, assume that who can publish to a repo you trust *is root* on your machine. Even if you could pin the package, what prevents him from adding a suid exe ? > Unless my system is misconfigured or other assumptions do not hold true, that > would imply, that the only security benefit from key pinning is only about > maintenance, making detection/pruning of stale keys easier. That's exactly what ther're for. BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
AW: AW: AW: Users GnuPG aims for? (Re: Breaking MIME concatenation)
> Von: Daniel Kahn Gillmor [mailto:d...@fifthhorseman.net] > > On Thu 2018-05-17 15:37:55 +, Fiedler Roman wrote: > > Von: Daniel Kahn Gillmor [mailto:d...@fifthhorseman.net] > > > >> See sources.list(5) and > >> https://wiki.debian.org/DebianRepository/UseThirdParty for more details. > >> > >> See also https://bugs.debian.org/877012 for suggestions about > >> improvements to scoped cryptographic authorities for the default > >> installation of debian repositories. > > > > Thanks for the information. I thought, that the new model would be > > using "/etc/apt/trusted.gpg.d", as recommended by an online version of > > "apt-key". > > I recommend not relying directly on apt-key, whether online or offline :) I see. If understood correctly, the trusted.gpg.d bypasses key management with apt-key completely, so not running into problems with apt-key deprecation. > > But of course the per-repository pinning of keys could make key > > management easier as there is a n:1 link between repositories and > > keys, thus it is easier to avoid stale keys in the common key storage > > file. > > yes. furthermore, per-repository pinning of keys avoids the possibility > of one repository owner signing a Release file for a different > repository... I thought about that also, but shouldn't 99%+ of systems perform no pinning whatsoever of packages to repositories? In that case, the "wrong" repository could publish just a slightly increased package version number of a package from another repository. Unattended updates will apply it anyway and also for users it would be hard noticing it: at least my "apt-get" version does not show any information about the repository a package would be downloaded from before confirming the installation. Thus the user would have to check each single package manually by invoking "apt-cache policy [pkg-name]" or use "apt-get download [packagelist]", check the logs and install packages with "dpkg". Unless my system is misconfigured or other assumptions do not hold true, that would imply, that the only security benefit from key pinning is only about maintenance, making detection/pruning of stale keys easier. > ... LG Roman ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AW: AW: Users GnuPG aims for? (Re: Breaking MIME concatenation)
On Thu 2018-05-17 15:37:55 +, Fiedler Roman wrote: > Von: Daniel Kahn Gillmor [mailto:d...@fifthhorseman.net] > >> See sources.list(5) and >> https://wiki.debian.org/DebianRepository/UseThirdParty for more details. >> >> See also https://bugs.debian.org/877012 for suggestions about >> improvements to scoped cryptographic authorities for the default >> installation of debian repositories. > > Thanks for the information. I thought, that the new model would be > using "/etc/apt/trusted.gpg.d", as recommended by an online version of > "apt-key". I recommend not relying directly on apt-key, whether online or offline :) > But of course the per-repository pinning of keys could make key > management easier as there is a n:1 link between repositories and > keys, thus it is easier to avoid stale keys in the common key storage > file. yes. furthermore, per-repository pinning of keys avoids the possibility of one repository owner signing a Release file for a different repository. This paves the way for a local administrator to put meaningful constraints on a given external repository (e.g. pinning which packages can be shipped from that repo, or restricting maintainer scripts from running). I welcome any and all help in continuing to drive the ecosystem down this path. Regards, --dkg signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
AW: AW: Users GnuPG aims for? (Re: Breaking MIME concatenation)
> Von: Daniel Kahn Gillmor [mailto:d...@fifthhorseman.net] > > On Thu 2018-05-17 08:45:18 +, Fiedler Roman wrote: > > As gnupg starts getting more and more problematic regarding some > > functions (see the discussions on command line/unattended use), Ubuntu > > Bionic AND Debian Buster dropped it from their debootstrap > > I don't know about Ubuntu Bionic, but for Debian Buster this is simply > false. > > Buster relies on gpgv (which is part of the GnuPG suite) for validating > archive signatures. That seems just a misunderstanding, as my initial message mentioning the changes was imprecise from my side, the follow-up https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060422.html should have made it clear, that we are both talking about the same thing. """Yes, but all those features do not apply to apt-key or are of little relevance. Hence gpg seems to have been included just for minimal use (just adding/removing keys, everything is trusted as performed by root user anyway). I do not know the reasons behind them dropping gpg, but I guess the just needed a failesafe, minimalistic tool for that purpose and now they dropped gpg and run only with gpgv to my knowledge.""" > > and replaced the apt-key management parts with own solutions. > > apt-key has been deprecated for a while now. I don't think i've seen a > secure use of apt-key that i can really encourage anywhere. > > If you want to do sane cryptographic controls on repositories, you > should (a) place the key for a given repo somewhere sensible in the > filesystem (e.g. /usr/share/keyrings/REPONAME-keyring.gpg), and (b) add > a Signed-By: line to your .sources file (or a signed-by option to the > line in your .list file). > > See sources.list(5) and > https://wiki.debian.org/DebianRepository/UseThirdParty for more details. > > See also https://bugs.debian.org/877012 for suggestions about > improvements to scoped cryptographic authorities for the default > installation of debian repositories. Thanks for the information. I thought, that the new model would be using "/etc/apt/trusted.gpg.d", as recommended by an online version of "apt-key". But of course the per-repository pinning of keys could make key management easier as there is a n:1 link between repositories and keys, thus it is easier to avoid stale keys in the common key storage file. > ... ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AW: Users GnuPG aims for? (Re: Breaking MIME concatenation)
On Thu 2018-05-17 08:45:18 +, Fiedler Roman wrote: > As gnupg starts getting more and more problematic regarding some > functions (see the discussions on command line/unattended use), Ubuntu > Bionic AND Debian Buster dropped it from their debootstrap I don't know about Ubuntu Bionic, but for Debian Buster this is simply false. Buster relies on gpgv (which is part of the GnuPG suite) for validating archive signatures. > and replaced the apt-key management parts with own solutions. apt-key has been deprecated for a while now. I don't think i've seen a secure use of apt-key that i can really encourage anywhere. If you want to do sane cryptographic controls on repositories, you should (a) place the key for a given repo somewhere sensible in the filesystem (e.g. /usr/share/keyrings/REPONAME-keyring.gpg), and (b) add a Signed-By: line to your .sources file (or a signed-by option to the line in your .list file). See sources.list(5) and https://wiki.debian.org/DebianRepository/UseThirdParty for more details. See also https://bugs.debian.org/877012 for suggestions about improvements to scoped cryptographic authorities for the default installation of debian repositories. > Hence "apt-key import" will not work any more on debootstrap templates > (thus in containerized environments) because gnupg is in process of > removal from essential system parts. Again, this is simply not true. e-mail itself (let alone encrypted mail) is not an essential system part, but cryptographic software update verification *is* an essential system part, and debian continues to depend on gpgv for that purpose. --dkg signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
AW: Users GnuPG aims for?
Just a foreword: sorry for not acknowledging all the good proposals you make - many of them I can fully second - and all the good changes you apply, I really appreciate them. I just do not reply to all of them ... > Von: Werner Koch [mailto:w...@gnupg.org] > > On Thu, 17 May 2018 10:45, roman.fied...@ait.ac.at said: > > > encryption/decryption gateways. In my opinion gnupg development has a > > strong motion towards client-only use-cases, thus I started like > > Huh? Didn't you noticed all the new features we implemented to make the > scripting of key managment easy or Those are really good, I am using them already. > the remote use gpg on servers with > private keys kept on the desktop or another secure box? Here I decided to implement my own solution as there is (was?) no option I would trust enough to reliably prohibit storage of any passphrases or unlocked keys in gpg agent when the key was used once. So agent is fine, but not for storing any unlocked key material. > ... > p.s: > Regarding my other point in this thread: Your mail is an example > for a hard to read one due to overlong lines and wrong localization of > the the "Re:" prefix in the the subject. I know that it is not your > fault but due to rong defaults of some MUAs. So right, I hate the company standard for that. Changing the prefix would trigger a bug/unexpected implicit behaviour of outlook, thus breaking thread view of common mailing list software. So I can only choose my poison. BTW: In my opinion, you are complete right on locating the fault on MUAs side for that. I fear, that one reason more for them being that bad in the office environment could be: who would want to have complex (and vulnerable, data leaking) desktop search engines indexing your mails, who would buy larger storages if mails were only 1-10% of size and could be quickly filtered by pure plaintext search, who would buy stronger processors, larger RAM required therefore? LG Roman ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
AW: Users GnuPG aims for?
> Von: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] Im Auftrag von > > Am Donnerstag 17 Mai 2018 10:45:18 schrieb Fiedler Roman: > > As gnupg starts getting more and more problematic regarding some > functions > > (see the discussions on command line/unattended use) > > Can you give me pointers here. > Even unattented use needs proper care of passphrases > (best is to leave them out) and status codes (which a command line cannot > usually handle well, thus gpgme for more complicated cases). There were quite many messages, that caused alarm bells ringing for me. Hard to dig them out all now. But maybe I am just over-sensitive to words between the lines or wrong in some other ways. Here are some examples: Pinentry: I for myself struggled with it also for a day, but also many other users have problems. Realizing, that gpg aims might be going into a different direction may motivate you to leave now before having to struggle again and maybe more at the next OS update, when you need to apply more workarounds. https://lists.gnupg.org/pipermail/gnupg-users/2018-March/060097.html (initramfs use) https://lists.gnupg.org/pipermail/gnupg-users/2015-March/053175.html (systemd "So it feels quite strange that i need to do all this juggling to get it working") Other examples: https://lists.gnupg.org/pipermail/gnupg-users/2016-February/055294.html (do not use gpg for encryption with different policies) https://lists.gnupg.org/pipermail/gnupg-devel/2016-September/031557.html (gpg-agent idle timeout workarounds) http://seclists.org/oss-sec/2017/q4/373 (a former gpg developer is explaining decisions, why he is implementing a new variant and his arguments (short lived processes) make completely sense for those usecases I envision, compare to the previous mail thread). > In my experience command line and unattended use is fully supported > and extended in GnuPG. It is just the rare unix system or very small system > space that may get more problematic because of different support libraries > and > system calls. GnuPG cannot implement all functionality it needs by itself > and thus we inherit some size and platform restrictions. That is understandable. But I cannot see the concept already, how this bloating can be avoided in future. And in the end gpg has to come up with some concept, e.g. regarding support of older mail message decryption modes plus all the libraries required to do that. Hence my critical remarks. > I wonder about pubkey management though. There is a faster pubkey store, > there are ways to automatically assign fetch pubkeys with basic trust (WKD) > and options to give a pubkey for just this encryption operation, those all > sound like improvements in the server use cases to me. Yes, but all those features do not apply to apt-key or are of little relevance. Hence gpg seems to have been included just for minimal use (just adding/removing keys, everything is trusted as performed by root user anyway). I do not know the reasons behind them dropping gpg, but I guess the just needed a failesafe, minimalistic tool for that purpose and now they dropped gpg and run only with gpgv to my knowledge. LG Roman ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
AW: Users GnuPG aims for? (Re: Breaking MIME concatenation)
> Von: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] Im Auftrag von > > Am Mittwoch 16 Mai 2018 15:46:05 schrieb Martin: > > I think a fundamental discussion is necessary with the question: Who > > should / will use GnuPG in the future? > > Note that during one contract in 2016 we came up with some thoughts > in where GnuPG could be heading: > https://wiki.gnupg.org/EasyGpg2016/VisionAndStories > > > Two extremes: Only these people who need really to encrypt their > > emails because they are persecuted. But these people learned how to > > handle their email client correctly and these people will write > > text-only also in the future. > > The problem stays viewing email contents. No, there is much more to it and I have the feeling, that GnuPG development does not really account for that, thus loosing grounds. As an example, gnupg is also key management. As gnupg starts getting more and more problematic regarding some functions (see the discussions on command line/unattended use), Ubuntu Bionic AND Debian Buster dropped it from their debootstrap and replaced the apt-key management parts with own solutions. Hence "apt-key import" will not work any more on debootstrap templates (thus in containerized environments) because gnupg is in process of removal from essential system parts. Even for more limited use-cases, like e-mail decryption: Some use it for client side de/encryption procedures, others use it server side in encryption/decryption gateways. In my opinion gnupg development has a strong motion towards client-only use-cases, thus I started like Ubuntu/Debian to get rid of in all server side applications. I do that as sysadmin-self-defence, but I do not like it from an ethical aspect: good encryption tools should be basics for a free digital society. This is also the reason why I participate in the discussion. LG Roman ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
