Re: [dev] dl.suckless.org file integrity github project

2017-08-30 Thread fao_

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

2017-08-28 Thread hiro
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

2017-08-28 Thread Anselm R Garbe
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

2017-08-28 Thread hiro
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

2017-08-28 Thread ilf

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

2017-08-27 Thread Anselm R Garbe
On 27 August 2017 at 00:19, Mattias Andrée  wrote:
> 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

2017-08-27 Thread Anselm R Garbe
On 26 August 2017 at 21:08, Laslo Hunhold  wrote:
> 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

2017-08-26 Thread Mattias Andrée
On Sat, 26 Aug 2017 21:05:25 +0200
Laslo Hunhold  wrote:

> 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

2017-08-26 Thread Laslo Hunhold
On Fri, 25 Aug 2017 13:54:41 +0200
Anselm R Garbe  wrote:

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

2017-08-26 Thread Laslo Hunhold
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

-- 
Laslo Hunhold 



Re: [dev] dl.suckless.org file integrity github project

2017-08-25 Thread Aaron Toponce
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

2017-08-25 Thread Mattias Andrée
On Fri, 25 Aug 2017 16:48:13 +0200
Anselm R Garbe  wrote:

> 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

2017-08-25 Thread Mattias Andrée
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.
> 
> 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

2017-08-25 Thread Anselm R Garbe
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



Re: [dev] dl.suckless.org file integrity github project

2017-08-25 Thread Laslo Hunhold
On Fri, 25 Aug 2017 08:12:12 +0200
Anselm R Garbe  wrote:

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

2017-08-25 Thread Nick
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

2017-08-25 Thread Anselm R Garbe
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

2017-08-25 Thread hiro
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

2017-08-24 Thread Nicolas Montanaro
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

2017-08-24 Thread christopher . waldon . dev
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

2017-08-24 Thread hiro
> 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

2017-08-24 Thread Hiltjo Posthuma
On Thu, Aug 24, 2017 at 12:02:35PM -0500, Joshua Haase wrote:
> Laslo Hunhold  writes:
> 
> > 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

2017-08-24 Thread Joshua Haase
Laslo Hunhold  writes:

> 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

2017-08-24 Thread Joshua Haase
Laslo Hunhold  writes:

> 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

2017-08-24 Thread Laslo Hunhold
On Thu, 24 Aug 2017 10:41:15 -0600
Aaron Toponce  wrote:

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

2017-08-24 Thread Nick
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

2017-08-24 Thread Aaron Toponce
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

2017-08-24 Thread 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.

-- 
. 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

2017-08-24 Thread Laslo Hunhold
On Thu, 24 Aug 2017 13:45:35 +0200
Hiltjo Posthuma  wrote:

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

2017-08-24 Thread Nick
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

2017-08-24 Thread ilf

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

2017-08-24 Thread Hiltjo Posthuma
On Thu, Aug 24, 2017 at 01:22:33PM +0200, Laslo Hunhold wrote:
> On Thu, 24 Aug 2017 11:02:46 +0200
> ilf  wrote:
> 
> 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

2017-08-24 Thread Hiltjo Posthuma
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

2017-08-24 Thread Laslo Hunhold
On Thu, 24 Aug 2017 11:02:46 +0200
ilf  wrote:

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

2017-08-24 Thread ilf

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

2017-08-23 Thread Anselm R Garbe
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

2017-08-23 Thread hiro
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

2017-08-23 Thread Markus Teich
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

2017-08-23 Thread Mattias Andrée
On Wed, 23 Aug 2017 22:29:17 +0200
Markus Teich  wrote:

> 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

2017-08-23 Thread Markus Teich
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

2017-08-23 Thread Mattias Andrée
On Wed, 23 Aug 2017 22:03:41 +0200
Markus Teich  wrote:

> 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

2017-08-23 Thread 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

2017-08-23 Thread Aaron Toponce
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

2017-08-23 Thread Hiltjo Posthuma
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

2017-08-23 Thread Aaron Toponce
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