Re: [dev] dl.suckless.org file integrity github project
On 2017-08-23 7:04 pm, Aaron Toponce wrote: I noticed most software available on http://dl.suckless.org does not provide checksums and digital signatures for the compressed tarballs, and other files. I sought to remedy this, by creating a Github repository of only checksums and digital signatures. It's available at: https://github.com/atoponce/dl.suckless.org Ultimately, it would be best if these were hosted on dl.suckless.org directly, but I figured I could help by hosting them here until they can get deployed. This is to help ensure that you have downloaded all the correct bits for both the software and the checksum. Hopefully, this is of some value to the community and suckless users, such as myself. I couldn't decide what subthread to add it to, so I'll put it on the root. As a side note, has anyone seen what OpenBSD did to handle and secure their project? I'll leave it here: https://www.openbsd.org/papers/bsdcan-signify.html -- - fao_ PGP fingerprint: 739B 6C5C 3DE1 33FA "Too enough is always not much!"
Re: [dev] dl.suckless.org file integrity github project
i'm not complaining, anselm. certain people need to stay busy in order to prevent other forms of harm. i'm happy you're putting more time lately to take care of all these kids here, thanks :)
Re: [dev] dl.suckless.org file integrity github project
On 28 August 2017 at 19:25, hiro <23h...@gmail.com> wrote: > wow, so much development going on in suckless these days. > i congratulate everybody involved in the lack of any shitty code > written. thanks. (and i am serious). Go ahead. I'm serious as well. -Anselm
Re: [dev] dl.suckless.org file integrity github project
wow, so much development going on in suckless these days. i congratulate everybody involved in the lack of any shitty code written. thanks. (and i am serious).
Re: [dev] dl.suckless.org file integrity github project
Thanks Anselm, this sounds awesome! Anselm R Garbe: - (optional) repo owners/maintainers should sign their future git tags for release creation by using their own private PGP key. I suggest distributing OpenPGP-keys via the keyserver pool [0] *without* self-hosting a copy. The point of keyservers is to allow faster distribution of changes like signatures, revocations, expirations - in an automated way [1, 2]. 0. https://sks-keyservers.net/ 1. https://github.com/ilf/gpg-maintenance 2. https://github.com/EtiennePerot/parcimonie.sh -- ilf Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes für Tastaturbenutzung signature.asc Description: PGP signature
Re: [dev] dl.suckless.org file integrity github project
On 27 August 2017 at 00:19, Mattias Andréewrote: > The user's must be able to find the appropriate keys some way the first > time, so suckless must at least have links to them. If suckless is > compromised these can be replaced. PGP keys only ensure that future > keys are not fraudulent as all new key should be signed by the old keys. > SSL certificates ensures that the PGP keys are not tempered with by > anyone outside suckless. Thus, hosting the keys one suckless.org, when > it has HTTPS, is more secure that every ones private home pages outside > suckless.org that do not have SSL certificates. Perhaps I'm old-fashioned, but in the older days there used to be the strategy to display your pgp fingerprint in mail signatures and lot's of other places, to ensure that during time and a high degree of footprint throughout the net, it would be a rather easy congnitive task to base trust on that. But I didn't notice this approach for a while and did stop it myself back in 2008 or so... BR, Anselm
Re: [dev] dl.suckless.org file integrity github project
On 26 August 2017 at 21:08, Laslo Hunholdwrote: > On Fri, 25 Aug 2017 13:54:41 +0200 > Anselm R Garbe wrote: >> Either that, or perhaps we can reinstate the old fashion of >> suckless.org/~user/ homedir. > > I gave it a bit more thought and realized that putting the keys all in > one place defeats the purpose of PGP. If the server is compromised, an > attacker would just have to additionally replace the keys in the > homedirs besides replacing the signed release-tarballs with fraudulent > ones that were signed with his "fraudulent" key. There's nothing wrong to put public keys onto suckless.org, in addition to a range of other places incl. official key servers. It would be a very poor assumption to only base a trust model on public keys found at the same place as some signatures. BR, Anselm
Re: [dev] dl.suckless.org file integrity github project
On Sat, 26 Aug 2017 21:05:25 +0200 Laslo Hunholdwrote: > On Fri, 25 Aug 2017 17:13:38 +0200 > Mattias Andrée wrote: > > Dear Mattias, > > > Each user could have a directory called pgp-keys and dl.suckless.org > > could list those directories. This would allow us to store old keys > > in a structured manner. > > > > An alternative is that the owner of a repo commits his key to the > > repo under /.pgp-keys. > > this is absolute insanity! This completely defeats the purpose of it. > If for some reason the suckless.org server is compromised, the > attacker can sign the fraudulent commits with his key and just replace > the one for the corresponding user on dl.suckless.org. > > PGP only works if the hosting is diverse, i.e. if the key is for > instance hosted on every project member's homepage. Can't we just stop > with this pseudo-security stuff? > > If somebody fiddled with the git-repo in some way, people would notice, > because many many people have copies of the tree on their computer. If > somebody somehow modified tags, or rebranched the repository, it would > be noticed. This is much more logical security approach which is > already in place. > Still, I'm not against signing tags with PGP keys, and as always, in > case I get something wrong, please let me know. > > With best regards > > Laslo > The user's must be able to find the appropriate keys some way the first time, so suckless must at least have links to them. If suckless is compromised these can be replaced. PGP keys only ensure that future keys are not fraudulent as all new key should be signed by the old keys. SSL certificates ensures that the PGP keys are not tempered with by anyone outside suckless. Thus, hosting the keys one suckless.org, when it has HTTPS, is more secure that every ones private home pages outside suckless.org that do not have SSL certificates.
Re: [dev] dl.suckless.org file integrity github project
On Fri, 25 Aug 2017 13:54:41 +0200 Anselm R Garbewrote: Dear Anselm, > Either that, or perhaps we can reinstate the old fashion of > suckless.org/~user/ homedir. I gave it a bit more thought and realized that putting the keys all in one place defeats the purpose of PGP. If the server is compromised, an attacker would just have to additionally replace the keys in the homedirs besides replacing the signed release-tarballs with fraudulent ones that were signed with his "fraudulent" key. With best regards Laslo -- Laslo Hunhold
Re: [dev] dl.suckless.org file integrity github project
On Fri, 25 Aug 2017 17:13:38 +0200 Mattias Andréewrote: Dear Mattias, > Each user could have a directory called pgp-keys and dl.suckless.org > could list those directories. This would allow us to store old keys > in a structured manner. > > An alternative is that the owner of a repo commits his key to the > repo under /.pgp-keys. this is absolute insanity! This completely defeats the purpose of it. If for some reason the suckless.org server is compromised, the attacker can sign the fraudulent commits with his key and just replace the one for the corresponding user on dl.suckless.org. PGP only works if the hosting is diverse, i.e. if the key is for instance hosted on every project member's homepage. Can't we just stop with this pseudo-security stuff? If somebody fiddled with the git-repo in some way, people would notice, because many many people have copies of the tree on their computer. If somebody somehow modified tags, or rebranched the repository, it would be noticed. This is much more logical security approach which is already in place. Still, I'm not against signing tags with PGP keys, and as always, in case I get something wrong, please let me know. With best regards Laslo -- Laslo Hunhold
Re: [dev] dl.suckless.org file integrity github project
On Fri, Aug 25, 2017 at 08:12:12AM +0200, Anselm R Garbe wrote: > - (optional) repo owners/maintainers should sign their future git tags > for release creation by using their own private PGP key. Optionally, for those who don't want to use OpenPGP, the author of libsodium created Minisign back in 2015. It only signs and verifies, and does not do any encryption or decryption, but it might be worth looking into for those who don't want to rely on OpenPGP keys. https://github.com/jedisct1/minisign -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o signature.asc Description: PGP signature
Re: [dev] dl.suckless.org file integrity github project
On Fri, 25 Aug 2017 16:48:13 +0200 Anselm R Garbewrote: > Hi Mattias, > > On 25 August 2017 at 16:32, Mattias Andrée wrote: > > On Fri, 25 Aug 2017 13:54:41 +0200 > > Anselm R Garbe wrote: > > > >> On 25 August 2017 at 12:56, Laslo Hunhold wrote: > >> > On Fri, 25 Aug 2017 08:12:12 +0200 > >> > Anselm R Garbe wrote: > >> >> - (optional) repo owners/maintainers should sign their future git tags > >> >> for release creation by using their own private PGP key. > >> > > >> > the public PGP-keys could be put on the > >> > http://suckless.org/people/*-pages. > >> > >> Either that, or perhaps we can reinstate the old fashion of > >> suckless.org/~user/ homedir. > > > > Wouldn't it be best to have all keys in one page? > > Sure it would, probably best is dl.suckless.org as well. > > My only concern with the wiki page is, that everybody could presumably > tamper the pubkeys there, since we accept upstream wiki changes. Of > course they need to be reviewed, but how do I know that Laslo's pubkey > is really Laslo's pubkey without hassle when reviewing some public > wiki change? > > Hence my suggestion to put them into a URL position that requires ssh > access for pushing onto suckless.org, which is given for > maintainers/repo owners. > > BR, > Anselm Each user could have a directory called pgp-keys and dl.suckless.org could list those directories. This would allow us to store old keys in a structured manner. An alternative is that the owner of a repo commits his key to the repo under /.pgp-keys. pgpwCiVeIBYSN.pgp Description: OpenPGP digital signature
Re: [dev] dl.suckless.org file integrity github project
On Fri, 25 Aug 2017 13:54:41 +0200 Anselm R Garbewrote: > On 25 August 2017 at 12:56, Laslo Hunhold wrote: > > On Fri, 25 Aug 2017 08:12:12 +0200 > > Anselm R Garbe wrote: > >> - (optional) repo owners/maintainers should sign their future git tags > >> for release creation by using their own private PGP key. > > > > the public PGP-keys could be put on the > > http://suckless.org/people/*-pages. > > Either that, or perhaps we can reinstate the old fashion of > suckless.org/~user/ homedir. > > BR, > Anselm > Wouldn't it be best to have all keys in one page? pgp2rJBh8bHLi.pgp Description: OpenPGP digital signature
Re: [dev] dl.suckless.org file integrity github project
On 25 August 2017 at 12:56, Laslo Hunholdwrote: > On Fri, 25 Aug 2017 08:12:12 +0200 > Anselm R Garbe wrote: >> - (optional) repo owners/maintainers should sign their future git tags >> for release creation by using their own private PGP key. > > the public PGP-keys could be put on the > http://suckless.org/people/*-pages. Either that, or perhaps we can reinstate the old fashion of suckless.org/~user/ homedir. BR, Anselm
Re: [dev] dl.suckless.org file integrity github project
On Fri, 25 Aug 2017 08:12:12 +0200 Anselm R Garbewrote: Dear Anselm, > - (optional) repo owners/maintainers should sign their future git tags > for release creation by using their own private PGP key. the public PGP-keys could be put on the http://suckless.org/people/*-pages. -- Laslo Hunhold
Re: [dev] dl.suckless.org file integrity github project
Quoth Joshua Haase: > It's not so many work if git is configured to always sign and/or the > package build system sign by default. Configuring git to sign every commit is a pain if you have a passphrase on your gpg key, or it's tied to a smartcard; entering that every time you commit makes the process a lot more annoying. Yes, I'm sure you could configure gpg-agent to some mode to mitigate that somewhat, but I don't think it's worth it. Just for each tag would be fine.
Re: [dev] dl.suckless.org file integrity github project
Hi there, let me summarise what we will carry out during the upcoming hackathon besides a load of other stuff: - (mandatory) introduction of HTTPS besides http support - (mandatory) sorting the maintainership/ownership of suckless repos (incl. the right to commit/accept/deny patch contributions) - (mandatory) on release creation making sure that sha256 hashsums are present for tarball verification on dl.suckless.org - (optional) repo owners/maintainers should sign their future git tags for release creation by using their own private PGP key. BR, Anselm
Re: [dev] dl.suckless.org file integrity github project
my grandmother also got all her pots stolen when she gave it to a person promising to bless them against bad ghosts. pgp is just a more modern version of that tale they told. some are apparently using the pgp tale to associate their names to random software projects. probably didn't manage to get the dish washer job, this is their way in to google.
Re: [dev] dl.suckless.org file integrity github project
I’m curious as to what the general criticisms of PGP are that sparked much of this discussion - I’m somewhat ignorant on the subject but the general consensus elsewhere seems to be that more PGP usage = better overall security. Would really like to learn a bit more about what issues it has. nsm signature.asc Description: Message signed with OpenPGP
Re: [dev] dl.suckless.org file integrity github project
I also support using openPGP signatures, at least optionally. I think that HTTPS would allay most of my concerns, but I'd like the option for further validation, and it's not hard to automate. -Chris On Aug 24, 2017, at 3:41 PM, hiro <23h...@gmail.com> wrote: >> does not hurt anyone and does not force >> anyone to use it. > > wtf is this bullshit rhetoric even called? > > i guess i'll keep on calling it mental retardation... >
Re: [dev] dl.suckless.org file integrity github project
> does not hurt anyone and does not force > anyone to use it. wtf is this bullshit rhetoric even called? i guess i'll keep on calling it mental retardation...
Re: [dev] dl.suckless.org file integrity github project
On Thu, Aug 24, 2017 at 12:02:35PM -0500, Joshua Haase wrote: > Laslo Hunholdwrites: > > > On Thu, 24 Aug 2017 11:02:46 +0200 > > ilf wrote: > > > > As nice as PGP sounds, I think it has seen its best days already for > > general usage. I know no package manager that implements this model > > (tell if there is one). The ones I know use hashes. > > pacman uses signatures to verify it's packages and a WoT stemming from > Arch developers which you have to accept locally. > > > But it means more work with questionable benefit. It's already > > difficult enough to keep the patches on the site up-to-date and even > > (as Hiltjo discovered) to provide checksums for all packages on > > dl.suckless.org. It's easy to delegate such things on the mailing > > list, proposing them (like in your position), but not actually doing > > anything. > > It's not so many work if git is configured to always sign and/or the > package build system sign by default. > Yes, part of this work is already done. On the hackathon is probably a good time to switch this over. I think signing should be done locally however by the repository maintainer or owner. -- Kind regards, Hiltjo
Re: [dev] dl.suckless.org file integrity github project
Laslo Hunholdwrites: > On Thu, 24 Aug 2017 13:45:35 +0200 > Hiltjo Posthuma wrote: > >> I think it's a good idea if we start to (optionally) sign (git) >> releases. This can be discussed further. > > This is something I would support! :) We could go as far to tell > dl.suckless.org to automatically generate tarballs and hashes from the > OpenPGP-signed git tags. +1
Re: [dev] dl.suckless.org file integrity github project
Laslo Hunholdwrites: > On Thu, 24 Aug 2017 11:02:46 +0200 > ilf wrote: > > As nice as PGP sounds, I think it has seen its best days already for > general usage. I know no package manager that implements this model > (tell if there is one). The ones I know use hashes. pacman uses signatures to verify it's packages and a WoT stemming from Arch developers which you have to accept locally. > But it means more work with questionable benefit. It's already > difficult enough to keep the patches on the site up-to-date and even > (as Hiltjo discovered) to provide checksums for all packages on > dl.suckless.org. It's easy to delegate such things on the mailing > list, proposing them (like in your position), but not actually doing > anything. It's not so many work if git is configured to always sign and/or the package build system sign by default.
Re: [dev] dl.suckless.org file integrity github project
On Thu, 24 Aug 2017 10:41:15 -0600 Aaron Toponcewrote: Hey Aaron, > There is no software on that github repository. It's all raw text. maybe it's all raw text to us now, but who says they won't add systemd-aarond to interpret this text as instructions to systemd to turn each and every single computer who neglectingly pulled your repositories into a bot? When it all comes crashing down on us, we'll all know what your true plan was. Well, at least your Skynet subjugation software was PGP-signed! With best regards Laslo -- Laslo Hunhold
Re: [dev] dl.suckless.org file integrity github project
Quoth Aaron Toponce: > On Thu, Aug 24, 2017 at 12:45:15AM +0200, hiro wrote: > > Any responsible suckless person should not download Aaron's software. > > I cannot guarantee it's not ransomware! > > There is no software on that github repository. It's all raw text. He's just trolling you, while implying that checksums can be used to imply more safety than they provide. Internet, eh?
Re: [dev] dl.suckless.org file integrity github project
On Thu, Aug 24, 2017 at 01:22:33PM +0200, Laslo Hunhold wrote: > I won't support the PGP snake-oil movement just so you can sleep well > at night. If you want to go with maximum trust, you can compare the > tarball-contents with the status of the git-repo at a certain tag. I'll continue to push checksums and PGP signatures to that respository. As an independent 3rd party who is not involved with any of the suckless projects, I can provide an neutral position on improving the integrity and security of the project, even if some find it too cumbersome to use, or aren't interested. > As nice as PGP sounds, I think it has seen its best days already for > general usage. I know no package manager that implements this model > (tell if there is one). The ones I know use hashes. All Fedora-based distributions (RHEL, CentoOS, Scientific, etc) use GPG-signed packages, and the package manager checks them by default. All Debian-based distrubitions (Debian, Ubuntu, Linux Mint, etc.) also use GPG-signed packages, and the package manager also checks them by default. Arch, Slackware, Gentoo, etc., etc., etc. It's more popular that the GNU/Linux distributions use GPG-signed software packages than not. > But it means more work with questionable benefit. It's already > difficult enough to keep the patches on the site up-to-date and even > (as Hiltjo discovered) to provide checksums for all packages on > dl.suckless.org. It's easy to delegate such things on the mailing > list, proposing them (like in your position), but not actually doing > anything. > Those doing the work are the ones that should be asked. The process can be automated by taking advantage of the GPG Agent. Some package building software will do this by default for you, by just supplying your GPG key. Of course, just building compressed tarballs, you would need to script it, but it's hardly challenging. -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o signature.asc Description: PGP signature
Re: [dev] dl.suckless.org file integrity github project
On Thu, Aug 24, 2017 at 12:45:15AM +0200, hiro wrote: > Any responsible suckless person should not download Aaron's software. > I cannot guarantee it's not ransomware! There is no software on that github repository. It's all raw text. -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o signature.asc Description: PGP signature
Re: [dev] dl.suckless.org file integrity github project
On Thu, 24 Aug 2017 13:45:35 +0200 Hiltjo Posthumawrote: Hey Hiltjo, > We must have scripts for this. Generating the SHA256 checksums was > easy. There were 2 checksums missing for surf which were fixed. If we > automate this then there is less chance to forget anything. We should > remove MD5 and SHA1 checksum support. agreed, SHA256 alone is sufficient imho. > I think it's a good idea if we start to (optionally) sign (git) > releases. This can be discussed further. This is something I would support! :) We could go as far to tell dl.suckless.org to automatically generate tarballs and hashes from the OpenPGP-signed git tags. With best regards Laslo -- Laslo Hunhold
Re: [dev] dl.suckless.org file integrity github project
FWIW, as someone who mostly just a user of suckless stuff, I like OpenPGP signing too. I don't have a strong opinion of git tags vs tarballs for signing, either is good. It's nice to have a properly secure proof of authenticity that doesn't depend on the link not being compromised. I'm really glad HTTPS is going to be rolled out to suckless.org soon, thanks for that! Personally I've gone off the web of trust model somewhat, it somewhat depends on long-lived keys, which given the lack of PFS is hard to manage securely. But OpenPGP signatures on software, from developers, is great. I plan of just doxing all of the suckless devs and knocking on their doors demanding to see their signatures. Much better. Or maybe checking them once on a different band to where I get the software... All depends on my mood. Nick Quoth Markus Teich: > Hiltjo Posthuma wrote: > > Checksums are available in each project directory, yesterday I've added > > SHA256 checksums. > > > > For example: > > SHA256: http://dl.suckless.org/dwm/sha256sums.txt > > SHA1: http://dl.suckless.org/dwm/sha1sums.txt > > MD5:http://dl.suckless.org/dwm/md5sums.txt > > > > HTTPs will be coming in a few weeks when some things are sorted. Maybe in > > the > > future we can add also add PGP signed releases. > > Heyho, > > I don't see the benefit of checksums without signatures. We already kind of > have > transmission integrity by IP for release downloads or by git. We really need > https, but PGP is probably controversial enough to be discussed. Maybe we have > some time for that at the hackathon, but that would exclude people who cannot > attend. > > Thus, start flaming your highly valued opinions about PGP-signing releases to > the list nao! ;P > > --Markus >
Re: [dev] dl.suckless.org file integrity github project
Laslo Hunhold: I know no package manager that implements this model (tell if there is one). https://wiki.debian.org/SecureApt Another cool project: https://hannes.nqsb.io/Posts/Conex But since suckless doesn't have an OS (yet), the debate is not about package managers, but source releases. And are many, many software projects out there that sign their releases with OpenPGP. -- ilf Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes für Tastaturbenutzung signature.asc Description: PGP signature
Re: [dev] dl.suckless.org file integrity github project
On Thu, Aug 24, 2017 at 01:22:33PM +0200, Laslo Hunhold wrote: > On Thu, 24 Aug 2017 11:02:46 +0200 > ilfwrote: > > Dear ilf, > > > HTTPS is good, and it's the new default: > > https://www.eff.org/deeplinks/2017/02/were-halfway-encrypting-entire-web > > The hierarchical trust model of X.509 make it suitable for many > > things, but for signing code that we build and run on our machines, I > > would like to use the strongest available trust model. > > given we don't PGP-sign our commits and suckless-projects are hosted on > the suckless server, going full overboard with PGP on the release-area > is overkill. > I won't support the PGP snake-oil movement just so you can sleep well > at night. If you want to go with maximum trust, you can compare the > tarball-contents with the status of the git-repo at a certain tag. > This only checks if the data is the same, not if it is signed/approved by the releaser. You probably know this, but there is a difference between normal git tags (reference) and a git annotated tag (used for PGP signs). git references can be easily modified. > > The OpenPGP "web of trust" might be a little clumsy to use for some > > people and others might not have a trust path to the signing key(s). > > But when you have verified the signing key, it's the strongest > > cryptographically verified trust method out there. I'm sure many > > people here can use it correctly, and surely it's now suckless' > > fault, if people use it wrong. > > As nice as PGP sounds, I think it has seen its best days already for > general usage. I know no package manager that implements this model > (tell if there is one). The ones I know use hashes. > This sounds outrageous, almost any serious distro implements this model in some way. For example OpenBSD signify(1). A list of hashes can be used for example if the ports are fetched in a trusted way (for example a ports.tgz in an OpenBSD release). > If you trust us suckless developers, you trust our server as well. > There is chance your connection is MITM'd, but we will counteract with > HTTPS. There's simply no reason to go further, given the entire > development model is not based on this kind of authentification model. > I disagree, it assumes as if we're the only part in the trust chain. Releases can/must be signed locally. > > Providing an OpenPGP signature does not hurt anyone and does not > > force anyone to use it. > > But it means more work with questionable benefit. It's already > difficult enough to keep the patches on the site up-to-date and even > (as Hiltjo discovered) to provide checksums for all packages on > dl.suckless.org. It's easy to delegate such things on the mailing > list, proposing them (like in your position), but not actually doing > anything. > Those doing the work are the ones that should be asked. > We must have scripts for this. Generating the SHA256 checksums was easy. There were 2 checksums missing for surf which were fixed. If we automate this then there is less chance to forget anything. We should remove MD5 and SHA1 checksum support. > > If people trust code from git, http or https - nice for them. > > If people trust checksums - nice for them. > > If people want to verify code authenticity and integrity via OpenPGP > > - please let them! > > How many people even do that? I guess the number is so low, it would > take less time to hand-pack a tarball for each after a personal request > per mail, provided of course they trust me. > But will you PGP sign the mail? :P I think it's a good idea if we start to (optionally) sign (git) releases. This can be discussed further. -- Kind regards, Hiltjo
Re: [dev] dl.suckless.org file integrity github project
On Thu, Aug 24, 2017 at 11:02:46AM +0200, ilf wrote: > I want to stronly advocate for OpenPGP signatures of releases. > > HTTPS is good, and it's the new default: > https://www.eff.org/deeplinks/2017/02/were-halfway-encrypting-entire-web > The hierarchical trust model of X.509 make it suitable for many things, but > for signing code that we build and run on our machines, I would like to use > the strongest available trust model. > > The OpenPGP "web of trust" might be a little clumsy to use for some people > and others might not have a trust path to the signing key(s). But when you > have verified the signing key, it's the strongest cryptographically verified > trust method out there. I'm sure many people here can use it correctly, and > surely it's now suckless' fault, if people use it wrong. > *not :) > Providing an OpenPGP signature does not hurt anyone and does not force > anyone to use it. > > If people trust code from git, http or https - nice for them. > If people trust checksums - nice for them. > If people want to verify code authenticity and integrity via OpenPGP - > please let them! > > Thanks, and keep up the good work! > > Mattias Andrée: > > * The number of people that actually know the developers of a individual > > package is negligible, so there isn't actually anyone that the users can > > trust. > I fully agree. We can use the technology since it's good "policy" anyway until the trust web expands. If we don't use it then it's assured it won't/can't be used. The first start is exchanging PGP keys when developers meet or can exchange keys securely. -- Kind regards, Hiltjo signature.asc Description: PGP signature
Re: [dev] dl.suckless.org file integrity github project
On Thu, 24 Aug 2017 11:02:46 +0200 ilfwrote: Dear ilf, > HTTPS is good, and it's the new default: > https://www.eff.org/deeplinks/2017/02/were-halfway-encrypting-entire-web > The hierarchical trust model of X.509 make it suitable for many > things, but for signing code that we build and run on our machines, I > would like to use the strongest available trust model. given we don't PGP-sign our commits and suckless-projects are hosted on the suckless server, going full overboard with PGP on the release-area is overkill. I won't support the PGP snake-oil movement just so you can sleep well at night. If you want to go with maximum trust, you can compare the tarball-contents with the status of the git-repo at a certain tag. > The OpenPGP "web of trust" might be a little clumsy to use for some > people and others might not have a trust path to the signing key(s). > But when you have verified the signing key, it's the strongest > cryptographically verified trust method out there. I'm sure many > people here can use it correctly, and surely it's now suckless' > fault, if people use it wrong. As nice as PGP sounds, I think it has seen its best days already for general usage. I know no package manager that implements this model (tell if there is one). The ones I know use hashes. If you trust us suckless developers, you trust our server as well. There is chance your connection is MITM'd, but we will counteract with HTTPS. There's simply no reason to go further, given the entire development model is not based on this kind of authentification model. > Providing an OpenPGP signature does not hurt anyone and does not > force anyone to use it. But it means more work with questionable benefit. It's already difficult enough to keep the patches on the site up-to-date and even (as Hiltjo discovered) to provide checksums for all packages on dl.suckless.org. It's easy to delegate such things on the mailing list, proposing them (like in your position), but not actually doing anything. Those doing the work are the ones that should be asked. > If people trust code from git, http or https - nice for them. > If people trust checksums - nice for them. > If people want to verify code authenticity and integrity via OpenPGP > - please let them! How many people even do that? I guess the number is so low, it would take less time to hand-pack a tarball for each after a personal request per mail, provided of course they trust me. With best regards Laslo -- Laslo Hunhold
Re: [dev] dl.suckless.org file integrity github project
I want to stronly advocate for OpenPGP signatures of releases. HTTPS is good, and it's the new default: https://www.eff.org/deeplinks/2017/02/were-halfway-encrypting-entire-web The hierarchical trust model of X.509 make it suitable for many things, but for signing code that we build and run on our machines, I would like to use the strongest available trust model. The OpenPGP "web of trust" might be a little clumsy to use for some people and others might not have a trust path to the signing key(s). But when you have verified the signing key, it's the strongest cryptographically verified trust method out there. I'm sure many people here can use it correctly, and surely it's now suckless' fault, if people use it wrong. Providing an OpenPGP signature does not hurt anyone and does not force anyone to use it. If people trust code from git, http or https - nice for them. If people trust checksums - nice for them. If people want to verify code authenticity and integrity via OpenPGP - please let them! Thanks, and keep up the good work! Mattias Andrée: * The number of people that actually know the developers of a individual package is negligible, so there isn't actually anyone that the users can trust. -- ilf Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes für Tastaturbenutzung signature.asc Description: PGP signature
Re: [dev] dl.suckless.org file integrity github project
On 24 August 2017 at 00:45, hiro <23h...@gmail.com> wrote: > Any responsible suckless person should not download Aaron's software. > I cannot guarantee it's not ransomware! > But I also made a github and my checksums and signatures are certified > by the German cybersecurity department of the TüV. My githab is called > honestachmet. Please add me to your linkedin. Actually the plan is to use HonestAchmed as our trusted CA for the upcoming TLS introduction on suckless.org ;) BR, Anselm
Re: [dev] dl.suckless.org file integrity github project
Any responsible suckless person should not download Aaron's software. I cannot guarantee it's not ransomware! But I also made a github and my checksums and signatures are certified by the German cybersecurity department of the TüV. My githab is called honestachmet. Please add me to your linkedin.
Re: [dev] dl.suckless.org file integrity github project
Mattias Andrée wrote: > * An alternative to signature files is to sign the tags in Git, and those > that care enough could pull releases from git instead. That is a nice idea. It doesn't require any extra signature/checksum file cruft on the webserver. It can easily be made optional and is in the maintainers hands if he wants to provide the signatures or not (with his own key). --Markus
Re: [dev] dl.suckless.org file integrity github project
On Wed, 23 Aug 2017 22:29:17 +0200 Markus Teichwrote: > Mattias Andrée wrote: > > If the server's authenticity can be proven with HTTPS, > > what additional secure does PGP-signatures provide? > > Some people trust persons they know more than they trust random corporations > with questionable security policies. Other people think PGP sucks. I don't > know > which group has the majority in the suckless community, thus I asked for a > gentle vote by flamewar. > > I count myself to the PGP proponents, but have to admit, that I might be too > lazy to check the PGP signatures myself. > > --Markus > In general PGP is good (of course, cryptography inherently sucks, but that's something we have to live with it), but it's just a hassle when in comes to software packages. There a few things to take into consideration when deciding what do here: * The number of people that actually know the developers of a individual package is negligible, so there isn't actually anyone that the users can trust. * It's probably easier to trust the developers than suckless itself. * If a user verifies that there is no history of malice up to a signed release, the user can to some extent trust the developer and the developer's signature can be used to verify that no one else on suckless cause the server to upload a malicious version. * An alternative to signature files is to sign the tags in Git, and those that care enough could pull releases from git instead. * Signature files allows all developers, not just the owner, to sign the release. * If signature files are added, people will probably make packages in repositories, such as the AUR, check the signature which can be a burden on the users which must add the developer's key to the keyring or disable signature checks. * If someone with root access to the suckless servers want to replace a release, he can serve the genuine version of the site to everyone who has connected to the server previously, and server a malicious version to new visitors, and have the PGP keys changed. * If a developer publishes a release, only root and that developer should be able to replace the release. * So do PGP keys actually add any security if have HTTPS, or do they just give a false sense of security.
Re: [dev] dl.suckless.org file integrity github project
Mattias Andrée wrote: > If the server's authenticity can be proven with HTTPS, > what additional secure does PGP-signatures provide? Some people trust persons they know more than they trust random corporations with questionable security policies. Other people think PGP sucks. I don't know which group has the majority in the suckless community, thus I asked for a gentle vote by flamewar. I count myself to the PGP proponents, but have to admit, that I might be too lazy to check the PGP signatures myself. --Markus
Re: [dev] dl.suckless.org file integrity github project
On Wed, 23 Aug 2017 22:03:41 +0200 Markus Teichwrote: > Hiltjo Posthuma wrote: > > Checksums are available in each project directory, yesterday I've added > > SHA256 checksums. > > > > For example: > > SHA256: http://dl.suckless.org/dwm/sha256sums.txt > > SHA1: http://dl.suckless.org/dwm/sha1sums.txt > > MD5:http://dl.suckless.org/dwm/md5sums.txt > > > > HTTPs will be coming in a few weeks when some things are sorted. Maybe in > > the > > future we can add also add PGP signed releases. > > Heyho, > > I don't see the benefit of checksums without signatures. We already kind of > have > transmission integrity by IP for release downloads or by git. We really need > https, but PGP is probably controversial enough to be discussed. Maybe we have > some time for that at the hackathon, but that would exclude people who cannot > attend. > > Thus, start flaming your highly valued opinions about PGP-signing releases to > the list nao! ;P > > --Markus > If the server's authenticity can be proven with HTTPS, what additional secure does PGP-signatures provide? pgpyvwYAkUP6J.pgp Description: OpenPGP digital signature
Re: [dev] dl.suckless.org file integrity github project
Hiltjo Posthuma wrote: > Checksums are available in each project directory, yesterday I've added > SHA256 checksums. > > For example: > SHA256: http://dl.suckless.org/dwm/sha256sums.txt > SHA1: http://dl.suckless.org/dwm/sha1sums.txt > MD5:http://dl.suckless.org/dwm/md5sums.txt > > HTTPs will be coming in a few weeks when some things are sorted. Maybe in the > future we can add also add PGP signed releases. Heyho, I don't see the benefit of checksums without signatures. We already kind of have transmission integrity by IP for release downloads or by git. We really need https, but PGP is probably controversial enough to be discussed. Maybe we have some time for that at the hackathon, but that would exclude people who cannot attend. Thus, start flaming your highly valued opinions about PGP-signing releases to the list nao! ;P --Markus
Re: [dev] dl.suckless.org file integrity github project
On Wed, Aug 23, 2017 at 08:21:45PM +0200, Hiltjo Posthuma wrote: > Checksums are available in each project directory, yesterday I've added > SHA256 checksums. > > For example: > SHA256: http://dl.suckless.org/dwm/sha256sums.txt > SHA1: http://dl.suckless.org/dwm/sha1sums.txt > MD5:http://dl.suckless.org/dwm/md5sums.txt Sweet! > Please don't use an external github for this, it sucks. I don't have access to the dl.suckless.org server, otherwise I would have just added them there. This is an alternative approach, and millions of people turn to Github for software. Thankfully, all you need is a git(1) client, and you can clone the repository locally, and never interact with the web interface, if you don't want to. :) -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o signature.asc Description: PGP signature
Re: [dev] dl.suckless.org file integrity github project
On Wed, Aug 23, 2017 at 12:04:46PM -0600, Aaron Toponce wrote: > I noticed most software available on http://dl.suckless.org does not provide > checksums and digital signatures for the compressed tarballs, and other files. > I sought to remedy this, by creating a Github repository of only checksums and > digital signatures. It's available at: > > https://github.com/atoponce/dl.suckless.org > > Ultimately, it would be best if these were hosted on dl.suckless.org directly, > but I figured I could help by hosting them here until they can get deployed. > This is to help ensure that you have downloaded all the correct bits for both > the software and the checksum. > > Hopefully, this is of some value to the community and suckless users, such as > myself. > > -- > . o . o . o . . o o . . . o . > . . o . o o o . o . o o . . o > o o o . o . . o o o o . o o o Hi, Checksums are available in each project directory, yesterday I've added SHA256 checksums. For example: SHA256: http://dl.suckless.org/dwm/sha256sums.txt SHA1: http://dl.suckless.org/dwm/sha1sums.txt MD5:http://dl.suckless.org/dwm/md5sums.txt HTTPs will be coming in a few weeks when some things are sorted. Maybe in the future we can add also add PGP signed releases. Please don't use an external github for this, it sucks. -- Kind regards, Hiltjo signature.asc Description: PGP signature
[dev] dl.suckless.org file integrity github project
I noticed most software available on http://dl.suckless.org does not provide checksums and digital signatures for the compressed tarballs, and other files. I sought to remedy this, by creating a Github repository of only checksums and digital signatures. It's available at: https://github.com/atoponce/dl.suckless.org Ultimately, it would be best if these were hosted on dl.suckless.org directly, but I figured I could help by hosting them here until they can get deployed. This is to help ensure that you have downloaded all the correct bits for both the software and the checksum. Hopefully, this is of some value to the community and suckless users, such as myself. -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o signature.asc Description: PGP signature