Re: [Haskell-cafe] Ticking time bomb

[Jon Fairbairn]

Marc Weber  writes:

> The only safe way is acceptnig keys from people you know don't view pdf
> using adobe reader,

I don’t…

> who don't browse the web (neither use flash) etc.

I only browse the web (in general) from a diskless virtual
machine.

> And then still you also have to know that their email account password
> is reasonable strong ..

I don’t think you need to know that: you need to know that their
signing key password is strong, that they’ve never entered it
into a machine with a keylogger running, and no-one has shoulder
surfed them. Oh, and that no-one can blackmail or torture them
:-P

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Marc Weber]

The only safe way is acceptnig keys from people you know don't view pdf
using adobe reader, who don't browse the web (neither use flash) etc.

And then still you also have to know that their email account password
is reasonable strong ..

So whatever this thread is about - its only about making it harder to
intentionally inject bad code.

Also "signed by two people" - how to verify that two accounts/email
addresses really belong to different people? - You understand the
problem.

Anyway - having signed packages is good, because attackers will be
slower, they have to build up trust first .. So it will improve the
situation a lot.

I also would appreciate being able to get hash sums from the
00-index.tar. Then automatic packaging is much easier.

Oh - and don't forgett the huge amount of code hackage has today.
It may not be feasable to trust - check all code - but having the most
used code checked by multiple parties alreday is a great improvement.

Marc Weber

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Alfredo Di Napoli]

+1 for keeping this alive.
Apart from the initial hype, now this issue is slowly losing attention but
I think we should always keep the risk we are exposed to.
Being I will sound pessimistic, but we should learn from the "competitors"
mistakes :)

Cheers,
A.

On 12 February 2013 08:49, Bob Ippolito  wrote:

> The Python and Ruby communities are actively working on improving the
> security of their packaging infrastructure. I haven't paid close attention
> to any of the efforts so far, but anyone working on cabal/hackage security
> should probably take a peek. I lurk on Python's catalog-sig list and here's
> the interesting bits I've noticed from the past few weeks:
>
> [Catalog-sig] [Draft] Package signing and verification process
> http://mail.python.org/pipermail/catalog-sig/2013-February/004832.html
>
> [Catalog-sig] [DRAFT] Proposal for fixing PyPI/pip security
> http://mail.python.org/pipermail/catalog-sig/2013-February/004994.html
>
> Python PyPi Security Working Document:
>
> https://docs.google.com/document/d/1e3g1v8INHjHsUJ-Q0odQOO8s91KMAbqLQyqj20CSZYA/edit
>
> Rubygems Threat Model:
> http://mail.python.org/pipermail/catalog-sig/2013-February/005099.html
>
> https://docs.google.com/document/d/1fobWhPRqB4_JftFWh6iTWClUo_SPBnxqbBTdAvbb_SA/edit
>
> TUF: The Update Framework
> https://www.updateframework.com/
>
>
>
> On Fri, Feb 1, 2013 at 4:07 AM, Christopher Done wrote:
>
>> Hey dude, it looks like we made the same project yesterday:
>>
>>
>> http://www.reddit.com/r/haskell/comments/17njda/proposal_a_trivial_cabal_package_signing_utility/
>>
>> Yours is nice as it doesn't depend on GPG. Although that could be a
>> nice thing because GPG manages keys. Dunno.
>>
>> Another diff is that mine puts the .sig inside the .tar.gz, yours puts
>> it separate.
>>
>> =)
>>
>> On 31 January 2013 09:11, Vincent Hanquez  wrote:
>> > On 01/30/2013 07:27 PM, Edward Z. Yang wrote:
>> >>
>> >> https://status.heroku.com/incidents/489
>> >>
>> >> Unsigned Hackage packages are a ticking time bomb.
>> >>
>> > I agree this is terrible, I've started working on this, but this is
>> quite a
>> > bit of work and other priorities always pop up.
>> >
>> > https://github.com/vincenthz/cabal
>> > https://github.com/vincenthz/cabal-signature
>> >
>> > My current implementation generate a manifest during sdist'ing in
>> cabal, and
>> > have cabal-signature called by cabal on the manifest to create a
>> > manifest.sign.
>> >
>> > The main issue i'm facing is how to create a Web of Trust for doing all
>> the
>> > public verification bits.
>> >
>> > --
>> > Vincent
>> >
>> >
>> > ___
>> > Haskell-Cafe mailing list
>> > Haskell-Cafe@haskell.org
>> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Bob Ippolito]

The Python and Ruby communities are actively working on improving the
security of their packaging infrastructure. I haven't paid close attention
to any of the efforts so far, but anyone working on cabal/hackage security
should probably take a peek. I lurk on Python's catalog-sig list and here's
the interesting bits I've noticed from the past few weeks:

[Catalog-sig] [Draft] Package signing and verification process
http://mail.python.org/pipermail/catalog-sig/2013-February/004832.html

[Catalog-sig] [DRAFT] Proposal for fixing PyPI/pip security
http://mail.python.org/pipermail/catalog-sig/2013-February/004994.html

Python PyPi Security Working Document:
https://docs.google.com/document/d/1e3g1v8INHjHsUJ-Q0odQOO8s91KMAbqLQyqj20CSZYA/edit

Rubygems Threat Model:
http://mail.python.org/pipermail/catalog-sig/2013-February/005099.html
https://docs.google.com/document/d/1fobWhPRqB4_JftFWh6iTWClUo_SPBnxqbBTdAvbb_SA/edit

TUF: The Update Framework
https://www.updateframework.com/



On Fri, Feb 1, 2013 at 4:07 AM, Christopher Done wrote:

> Hey dude, it looks like we made the same project yesterday:
>
>
> http://www.reddit.com/r/haskell/comments/17njda/proposal_a_trivial_cabal_package_signing_utility/
>
> Yours is nice as it doesn't depend on GPG. Although that could be a
> nice thing because GPG manages keys. Dunno.
>
> Another diff is that mine puts the .sig inside the .tar.gz, yours puts
> it separate.
>
> =)
>
> On 31 January 2013 09:11, Vincent Hanquez  wrote:
> > On 01/30/2013 07:27 PM, Edward Z. Yang wrote:
> >>
> >> https://status.heroku.com/incidents/489
> >>
> >> Unsigned Hackage packages are a ticking time bomb.
> >>
> > I agree this is terrible, I've started working on this, but this is
> quite a
> > bit of work and other priorities always pop up.
> >
> > https://github.com/vincenthz/cabal
> > https://github.com/vincenthz/cabal-signature
> >
> > My current implementation generate a manifest during sdist'ing in cabal,
> and
> > have cabal-signature called by cabal on the manifest to create a
> > manifest.sign.
> >
> > The main issue i'm facing is how to create a Web of Trust for doing all
> the
> > public verification bits.
> >
> > --
> > Vincent
> >
> >
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Richard O'Keefe]

On 1/02/2013, at 3:32 PM, Kevin Quick wrote:

> Without details of git's trust/verification model, it's difficult to see how 
> this particular SCM tool provides the trust capabilities being discussed any 
> better than a more focused solution.  Additionally, the use of git is also 
> difficult for many Windows users (80MB installed footprint, last I tried).

Put it on an outboard 1.5TB drive (price about $100) and it will
take about 1/18,000th of the space.  And Windows Update downloads about that
amount or more in patches every time I log in (about once a fortnight).

So it can't really be the size that makes git-on-Windows difficult.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Vincent Hanquez]

On Fri, Feb 01, 2013 at 01:07:33PM +0100, Christopher Done wrote:
> Hey dude, it looks like we made the same project yesterday:
> 
> http://www.reddit.com/r/haskell/comments/17njda/proposal_a_trivial_cabal_package_signing_utility/
> 
> Yours is nice as it doesn't depend on GPG. Although that could be a
> nice thing because GPG manages keys. Dunno.
> 
> Another diff is that mine puts the .sig inside the .tar.gz, yours puts
> it separate.

Nice to see a productive discussion on this. /me really need to read reddit 
more :)

Couple of details, no the signature is going inside the tarball too.  the
signature process happens during the sdisting after building the manifest.  My
reason for doing is, which i suspect similar to yours, is that I don't need to
modify hackage this way and the uploading stays the same. Also in my case,
cabal-signature is called by cabal, not by the user. I can't see this effort
working without forcing everyone to use it (transparently in the background)

For gpg, i don't know what's the right answer. One on hand it's solving all
the problems related to this already, but on the other portability issue.

I was thinking maybe one way to verify the key that i use for signing,
would be to tie it to a personal gpg key (by signing the key with a gpg key) to
benefit from all the facilities that gpg provides. It would provide a cheap way
to switch model later, without being tied to a gpg signing process.

-- 
Vincent

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Christopher Done]

Hey dude, it looks like we made the same project yesterday:

http://www.reddit.com/r/haskell/comments/17njda/proposal_a_trivial_cabal_package_signing_utility/

Yours is nice as it doesn't depend on GPG. Although that could be a
nice thing because GPG manages keys. Dunno.

Another diff is that mine puts the .sig inside the .tar.gz, yours puts
it separate.

=)

On 31 January 2013 09:11, Vincent Hanquez  wrote:
> On 01/30/2013 07:27 PM, Edward Z. Yang wrote:
>>
>> https://status.heroku.com/incidents/489
>>
>> Unsigned Hackage packages are a ticking time bomb.
>>
> I agree this is terrible, I've started working on this, but this is quite a
> bit of work and other priorities always pop up.
>
> https://github.com/vincenthz/cabal
> https://github.com/vincenthz/cabal-signature
>
> My current implementation generate a manifest during sdist'ing in cabal, and
> have cabal-signature called by cabal on the manifest to create a
> manifest.sign.
>
> The main issue i'm facing is how to create a Web of Trust for doing all the
> public verification bits.
>
> --
> Vincent
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Alexander Kjeldaas]

Forgot the list.


On Fri, Feb 1, 2013 at 10:21 AM, Alexander Kjeldaas <
alexander.kjeld...@gmail.com> wrote:

>
> Trying to avoid the wrath of Ketil I'll refrain from suggesting to do
> anything, I'll just explain why git is good at this, and not arbitrary. :-)
>
> Most systems that I know of to verify *anything*, use merkle trees, or
> something very similar.
> http://en.wikipedia.org/wiki/Hash_tree
>
> For example the TPM chip on your motherboard, used for example to ensure
> the integrity of the Google Chromebook and Windows BitLocker
> http://en.wikipedia.org/wiki/Trusted_Platform_Module
> (simplified example: in secure memory it stores H1=hash(microcode), then
> H2=hash(H1 || BIOS), then H3=hash(H2 || MBR), then H4=hash(H3 || kernel),
> ...).
>
> Or the integrity of the bitcoin currency.
> https://en.bitcoin.it/wiki/Protocol_specification#Merkle_Trees
>
> So these are pretty different systems, but it all boils down to doing
> cryptographic secure hashes over a previous hash + new data to ensure
> integrity of the new combined data.  Given only one verified hash in such a
> system, no part of the data, nor its history of mutation can be forged.
>  "History" can mean which software runs on your computer (TPM), which
> transactions are valid (Bitcoin), or which commits have been done in a SCM
> (git, mercurial).
>
> So git is not magical, it is just a practical implementation of something
> that works.  Any other *general* solution will be based on similar basic
> principles.  Mercurial does this and there is a GPG extension for it.
>
> Bazaar does not use a SHA1-based content addressable storage, so while a
> signed commit signs the tree, it does not represent the history (no "hash
> of hash", only "hash" if you look at it as a merkle tree), but it does
> chain commits. To verify a tree + history, *all* commits must be signed,
> which is fragile IMO.
>
> Regarding Darcs, my understanding is that it deliberately rejects hashing
> the tree, so it is not clear to me how to verify tree+history.  Patches can
> be signed, but as long as patches are independent, there is no "hash of
> hash" component which makes it difficult to see how one can verify the
> tree.  My understanding of darcs is very limited though.
>
> But to be *practical* the rest of the workflow should be secure as well,
> so you need:
>
> 1. A way to distribute the merkle tree (git pull/clone/push).
> Distribution is of the data that is to be signed is required for
> security, because otherwise the representation of the data itself (web view
> or 'git diff') can be compromised.  Signatures have no meaning if you
> cannot trust that you know what you sign.
> 2. A way to sign a change to the merkle tre (git commit -S, git tag -s etc)
> 3. A way to have multiple signatures on a given hash (i.e. commit, or tag,
> or whatever it is called in a particular merkle tree implementation).
> This is required to avoid catastrophic "owning" of core developers.
>  If required, I do think that multiple signatures can be emulated by a
> structured set of commits that have single signatures though.
> 3. A way to reliably do code reviews on the changes to the data (git diff)
> This is really the same as 1).  We cannot reliably do 'git diff'
> unless the developers do it on their own equipment, thus the system must be
> distributed.
> 4. Given the requirement for a distributed merkle tree, some merge
> strategy is needed.  It is thus practical, though not required, to have
> good support for this.
> (Btw, even the bitcoin hash chain has a merge strategy - the tree with
> the most compute power will win, and others are forced to "rebase" their
> transactions on that tree)
>
>
> So my choice of git is not arbitrary.  The way git works is pretty
> fundamental to verifying the integrity of stuff.
>
> Though when I have looked through the other options, mercurial might be a
> better fit since it is supported on Windows.
>
> Trying to solve this problem from scratch might not be such a good idea,
> because it might be very close to a reimplementation of git or mercurial.
>  Or maybe it is a good idea for someone who has some time on their hands.
>  Just be aware that the requirements for verifying anything is very close
> to what existing distributed SCM systems do.
>
> Alexander
>
>
> On Fri, Feb 1, 2013 at 3:32 AM, Kevin Quick  wrote:
>
>> Git has the ability to solve all of this.
>>>
>> ...
>>
>>  2. Uploads to hackage either happen through commits to the git
>>> repository,
>>> or an old-style upload to hackage automatically creates a new anonymous
>>> branch in the git repository.
>>> 3. The git repository is authorative.  Signing releases, code reviews
>>> etc.
>>> all happens through the git repositories.  This gives us all the
>>> flexibility of a git-style trust model.
>>>
>> ...
>>
>>  5. Who owns which package names can be held in a separate meta-tree git
>>> repository, and can have consensus requirements on commits.
>>> 6. This special me

Re: [Haskell-cafe] Ticking time bomb

[Kevin Quick]

Git has the ability to solve all of this.

...
2. Uploads to hackage either happen through commits to the git  
repository,

or an old-style upload to hackage automatically creates a new anonymous
branch in the git repository.
3. The git repository is authorative.  Signing releases, code reviews  
etc.

all happens through the git repositories.  This gives us all the
flexibility of a git-style trust model.

...

5. Who owns which package names can be held in a separate meta-tree git
repository, and can have consensus requirements on commits.
6. This special meta-tree can also contain suggested verification keys  
for

commits to the other hackage git trees.  It can even contain keys that
protect Haskell namespaces in general, so that no hackage package can
overwrite a protected Haskell namespace.
7. As backward compatibility, the meta-tree can sign simple hashes of
already existing packages on hackage.

...

1. There could be some git magic script that downloads the signed git tag
objects only (small data set).  Then another script would generate a
git-compatible SHA1 of the extracted tarball, given that the tarball was
fetched from hackage.
2. Or cabal-install could fetch directly from git repositories and use
standard git verification.
3. Or a trusted machine creates tarballs from the git repositories, signs
them and uploads them to hackage.


Without details of git's trust/verification model, it's difficult to see  
how this particular SCM tool provides the trust capabilities being  
discussed any better than a more focused solution.  Additionally, the use  
of git is also difficult for many Windows users (80MB installed footprint,  
last I tried).  git has a much broader solution space than simply ensuring  
the integrity of package downloads, especially when "there could be some  
git magic script" that is still not identified and appears to have the  
same insecurities as the package download/upload itself.


Instead of using the "git" solution and looking for problems to solve with  
it, IMHO we should work from clearly defined problem to solution in  
general terms as our class, and then determine what specific tools  
represent an instance of that  solution class.


--
-KQ

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Bardur Arantsson]

On 01/30/2013 08:27 PM, Edward Z. Yang wrote:
> https://status.heroku.com/incidents/489
> 
> Unsigned Hackage packages are a ticking time bomb.
> 

Somewhere else that shall not be mentioned, someone posted this link
which points to an interesting solution to this problem:

   http://www.futurealoof.com/posts/nodemodules-in-git.html

It requies a little basic knowledge of the Node Package Manager to
understand. Here's a little summary that should it easier to understand
for people who are not familiar with NodeJS:

The Node Package Manager (npm) is the Node JS equivalent of
cabal-install(*).

When you install a module (think Haskell package off Hackage) using
"npm", it installs into a directory called "node_modules" in the
project's directory instead of installing into a global name space.

When a NodeJS program imports a required module, it is first looked up
in the "node_modules" directory _before_ looking in the global package
database.

Since modules *are* their source, you can check all of this into the
revision control system of your choice.

It seems to me that "cabal install" could do something very similar to
solve many of the "cabal hell" and potential security issues when users
blindly do "cabal install".

(*) Yeah, yeah, not a package manager. In practice it's being used as
one, so...



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Alexander Kjeldaas]

On Thu, Jan 31, 2013 at 12:53 PM, Ketil Malde  wrote:

>
> Ertugrul Söylemez  writes:
>
> > And that may even be more harmful, because an insecure system with a
> > false sense of security is worse than an insecure system alone.
>
> Yes.  As is clear to all, the current low level of security means that
> nobody are _actually_ downloading stuff of Hackage, thank God.  Hackage
> just exists for...well, I forget, but certainly not to distribute
> software.  Right.
>
> Sarcasm aside, to some extent, this is true.  I used to have a cron job
> 'cabal install'ing my packages off Hackage to ensure that they would
> compile with the current offering of their dependencies.  But I decided
> it was way too risky, and don't do it anymore.
>
> > Let's do it properly.
>
> You mean like how it was decisively dealt with when this was discussed
> in 2008?
>
>   https://github.com/haskell/cabal/issues/207
>
> Or maybe more the way it was firmly handled when it was brought up again
> in 2010?
>
>   http://www.haskell.org/pipermail/haskell-cafe/2010-December/087050.html
>
> This looks increasingly like that time of year when the problem is
> pointed out, the crypto geeks get together to construct the Optimal
> Solution, and then everybody lose interest and move on to greener
> pastures for a while.  Well, I don't think the perfect solution exists,
> and even if
> it could be identified, it might not be implemented, and even if
> were implemented, it might not be used.
>
>
Hehe.. hard to argue against history! :-)

Alexander



> We've just been incredibly lucky that nothing really bad has happened so
> far.  Let's hope it lasts.
>
> -k
> --
> If I haven't seen further, it is by standing in the footprints of giants
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Ketil Malde]

Ertugrul Söylemez  writes:

> And that may even be more harmful, because an insecure system with a
> false sense of security is worse than an insecure system alone.

Yes.  As is clear to all, the current low level of security means that
nobody are _actually_ downloading stuff of Hackage, thank God.  Hackage
just exists for...well, I forget, but certainly not to distribute
software.  Right.

Sarcasm aside, to some extent, this is true.  I used to have a cron job
'cabal install'ing my packages off Hackage to ensure that they would
compile with the current offering of their dependencies.  But I decided
it was way too risky, and don't do it anymore.

> Let's do it properly.

You mean like how it was decisively dealt with when this was discussed
in 2008?

  https://github.com/haskell/cabal/issues/207

Or maybe more the way it was firmly handled when it was brought up again
in 2010? 

  http://www.haskell.org/pipermail/haskell-cafe/2010-December/087050.html

This looks increasingly like that time of year when the problem is
pointed out, the crypto geeks get together to construct the Optimal
Solution, and then everybody lose interest and move on to greener
pastures for a while.  Well, I don't think the perfect solution exists, and 
even if
it could be identified, it might not be implemented, and even if
were implemented, it might not be used.

We've just been incredibly lucky that nothing really bad has happened so
far.  Let's hope it lasts.

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Alexander Kjeldaas]

On Thu, Jan 31, 2013 at 11:40 AM, Vincent Hanquez  wrote:

> On 01/31/2013 10:06 AM, Ertugrul Söylemez wrote:
>
>> Joachim Breitner  wrote:
>>
>>  And that may even be more harmful, because an insecure system with a
 false sense of security is worse than an insecure system alone.

 Let's do it properly.

>>> but don’t overengineer it either. Simply adding to hackage the
>>> possibility to store a .asc file next to the tar.gz file that contains
>>> the cryptographic signature would be a great start, and allow us to
>>> develop a WoT model later on.
>>>
>>> (I try to resist from wondering whether this could go into hackage1 or
>>> only hackage2, and in the latter case, whether that means that we
>>> actually have the time to overengineer the system.)
>>>
>>> In fact, a lot would already be gained by a simple „warn if foo-2.0 is
>>> signed with a different key than the version of foo already installed“
>>> on cabal-install and people having a closer look at uploads from
>>> different people. Not much infrastructure needed there.
>>>
>> That was exactly my suggestion actually.  It requires the ability to
>> make and check signatures.  The making can be done with external tools
>> like GnuPG, but the checking has to be done by cabal-install.  To detect
>> changed keys there also needs to be a trust database, which can be a
>> simple directory in ~/.cabal/ where files are named after the
>> fingerprint of the key it contains.
>>
>> The most important part is a sensible user interface.  The whole process
>> should be invisible to the user, until there is a signature error.  The
>> first installation of a package will actually generate a handful of
>> signature errors, because the keys are not known yet.
>>
>> This shouldn't be too hard to implement and requires only a small change
>> to Hackage and cabal-install's upload command to begin.
>>
>
> That's not a proper solution, and definitively in the warm fuzzy feeling
> department.
>
> What if you install a package for the first time and this package has just
> been re-uploaded maliciously with a different key and a payload ?
> What if you're relying on hackage mirrors, what stop this mirror to
> regenerate all signatures with a new key ?
>
> It also make maintainers change difficult, and doing genuine
> non-maintainer upload.
>
>
It is still useful to protect "most users" and detect malicious code
"really quickly".  Someone will always have the package installed and will
notice, so the intruder will only be able to do very targeted attacks.

Basically this creates at chain of trust for each package.  What I think
you want is a chain of trust between packages.

Alexander


>
> --
> Vincent
>
> __**_
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/**mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Ketil Malde]

Vincent Hanquez  writes:

> On 01/31/2013 08:16 AM, Ketil Malde wrote:

>> At least that way, I would be notified if it happened to my packages,
>> and I would be able to check up on the situation, and rectify it.

> you wouldn't in real cases, 

I wouldn't what?  Be notified?  Rectify it?

> it just fix the most obvious and simple attack vector. 

> but consider:

Ah, those _real_ cases. Fine, let's see what you got.

> * someone intercepting your upload http stream, and replacing 
> dynamically your package.

> * someone gaining malicious access to hackage and planting stuff inside 
> packages.

> * a rogue hackage admin.

> * a rogue hackage mirror admin.

How often do these things happen, I wonder?  I guess a bit more rarely
than malware taking control of people's computers, which would simply
allow people access to upload passwords _and_ signing keys.  So much for
that perfect security scheme, huh?

Anyway: I don't want to sound negative here, so as a constructive
proposal, please replace one of my packages on Hackage, making use of
one of those techniques.  No hurry, I'll wait.

We have this discussion every now and then, and in spite of grand
schemes of crypto and signing and whatnot, we _still_ have security
holes you could drive a truck through.  Why not at least do _something_
to fix that, before we return to the more _interesting_ pursuit of the
Perfect Security Scheme?

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Alexander Kjeldaas]

On Thu, Jan 31, 2013 at 11:48 AM, Vincent Hanquez  wrote:

> On 01/31/2013 08:54 AM, Alexander Kjeldaas wrote:
>
>> On Thu, Jan 31, 2013 at 9:26 AM, Vincent Hanquez  wrote:
>>
>>  On 01/31/2013 06:27 AM, Ertugrul Söylemez wrote:
>>>
>>>  In any case there is no valid excuse for the lack of crypto.  It's too
 easy to attack Hackage, so we need some crypto regardless of what we
 interpret it as.

 My proposal is:

 1. Build the necessary machinery into Cabal to allow signing keys
 and
packages and verifying the signatures, ideally through GnuPG.
Cabal would benefit from that even without cabal-install and
Hackage.

  Seems there's lots of suggestion of using gnupg, which is a perfectly
>>> valid answer if cabal was unix only, but i'm not sure it's a valid option
>>> considering windows. Sure you can install gnupg somehow, but sounds to me
>>> it's going the same problem as gtk2hs on windows.
>>>
>>> One better way, would be to tap in the 2, work in progress, gnupg haskell
>>> replacement:
>>>
>>> http://hackage.haskell.org/package/openpgp
>>> 
>>> >
>>> http://hackage.haskell.org/package/hOpenPGP
>>> 
>>> >
>>>
>>>
>>> AFAIK, both packages are not yet handling anything related to WoT, but
>>> just do the signing/verification (which is same status as my ad-hoc
>>> experiment)
>>>
>>>
>>>  In this case I think this is the wrong approach.  There must be at least
>> one way to work within a trust model that is not fragile.  Whether this is
>> fully supported on all platforms is actually not very important.
>>
>> I have pointed out why simply signing packages is fragile and how git is
>> better suited for this task.  We are not going to reimplement all the good
>> infrastructure that already exists (gpg, git), so making that a
>> requirement
>> is not a good idea IMO.
>>
>> Basic verification of signatures should work on Windows, I agree.  But the
>> underlying WoT should be a little bit more sophisticated.  This means it
>> has to be based on standard tools, or it will never happen.
>>
>>  I think you misunderstood me.
>
> Having a fully working pgp package, means you have full control of the pgp
> stack, you don't rely on hard-to-get out tools, and it can be integrated
> with cabal directly for a full WoT experience.
>
> Also git doesn't solve the hackage problem, there's not necessarily a
> one-to-one mapping between packages and their repositories.
>
>
Regarding git, I don't see anyone even suggesting that hackage should
support multiple 'signed-off-by's, signing diffs between packages, and
signing releases.  I don't see anyone supporting 3rd-parties signing
packages at will.

All of this is significant engineering effort that just won't happen.

And even if it does, it still doesn't solve the problem, because all of the
above is required to protect our base ghc, cabal-install tools anyways.  If
cabal-install is hacked, hackage is hacked.

And even when all of this is done, a design where there is a set of trusted
developers is flawed.  The set of trusted developers will increase over
time, and there will be the need to restrict which developers can release
which package.

How do you protect that information, which keys can sign which packages?
 That information must itself be signed off by someone.  If not, ouch some
obscure developer in the trusted set hijacked an important package because
he was owned.

That signing in itself *requires* either consensus or a trusted third
party.  Consensus is a superior method and IMO required.

Actually, all modifications to important packages requires consensus by at
least two developers to avoid the threat posed by "owned" developers.

So although it is not a waste of time to "secure" hackage, it is always
going to be slightly fragile as long as ghc is fragile for example, and it
just isn't ever going to *really* solve the problem.

Git has the ability to solve all of this.

So a better use of resources IMO is to skip securing hackage by own means,
but to standardize on using git as the infrastructure for securing hackage.
 Then the same infrastructure that should secure ghc should secure hackage.

To explain this in concrete terms, to do this, all that is needed is
*something like* the following:

1. Each package on hackage gets its own repository (say on github or
similar).
(I've actually put all of hackage in a single git repository - it works
fine, so there are no relevant size problems)
2. Uploads to hackage either happen through commits to the git repository,
or an old-style upload to hackage automatically creates a new anonymous
branch in the git repository.
3. The git repository is authorative.  Signing 

Re: [Haskell-cafe] Ticking time bomb

[Twan van Laarhoven]

On 31/01/13 09:16, Ketil Malde wrote:

*MY* proposal is that:

0. Hackage sends an email to the previous uploader whenever a new
version of a package is uploaded by somebody else.

At least that way, I would be notified if it happened to my packages,
and I would be able to check up on the situation, and rectify it.

This is not to say that cryptographic signing is the wrong thing to do,
but a very simple thing like this, which would probably take all of five
minutes to implement, would reduce risk by a substantial amount.



That is an excellent idea, and it should be very simple to add.

Of course it doesn't stop all attacks, but it does stop the most obvious one. 
And it might also prevent some honest mistakes or errors in communication where 
someone uploads a forked package without permission.



Twan


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Ertugrul Söylemez]

Vincent Hanquez  wrote:

> > That was exactly my suggestion actually.  It requires the ability to
> > make and check signatures.  The making can be done with external
> > tools like GnuPG, but the checking has to be done by cabal-install.
> > To detect changed keys there also needs to be a trust database,
> > which can be a simple directory in ~/.cabal/ where files are named
> > after the fingerprint of the key it contains.
> >
> > The most important part is a sensible user interface.  The whole
> > process should be invisible to the user, until there is a signature
> > error.  The first installation of a package will actually generate a
> > handful of signature errors, because the keys are not known yet.
> >
> > This shouldn't be too hard to implement and requires only a small
> > change to Hackage and cabal-install's upload command to begin.
>
> That's not a proper solution, and definitively in the warm fuzzy
> feeling department.
>
> What if you install a package for the first time and this package has
> just been re-uploaded maliciously with a different key and a payload ?
> What if you're relying on hackage mirrors, what stop this mirror to
> regenerate all signatures with a new key ?
>
> It also make maintainers change difficult, and doing genuine
> non-maintainer upload.

See the last point of my post.  The last step is to implement proper web
of trust functionality, so that some keys can be declared to be signing
keys.  Then a set of trusted keys can be shipped together with
cabal-install.

That step is optional, because at least now I can fetch developer keys
by other means like a key server.

According to my solution Cabal warns for new and changed keys and asks
whether to trust them showing a fingerprint.


Greets,
Ertugrul

-- 
Key-ID: E5DD8D11 "Ertugrul Soeylemez "
FPrint: BD28 3E3F BE63 BADD 4157  9134 D56A 37FA E5DD 8D11
Keysrv: hkp://subkeys.pgp.net/


signature.asc
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Vincent Hanquez]

On 01/31/2013 08:54 AM, Alexander Kjeldaas wrote:

On Thu, Jan 31, 2013 at 9:26 AM, Vincent Hanquez  wrote:


On 01/31/2013 06:27 AM, Ertugrul Söylemez wrote:


In any case there is no valid excuse for the lack of crypto.  It's too
easy to attack Hackage, so we need some crypto regardless of what we
interpret it as.

My proposal is:

1. Build the necessary machinery into Cabal to allow signing keys and
   packages and verifying the signatures, ideally through GnuPG.
   Cabal would benefit from that even without cabal-install and
   Hackage.


Seems there's lots of suggestion of using gnupg, which is a perfectly
valid answer if cabal was unix only, but i'm not sure it's a valid option
considering windows. Sure you can install gnupg somehow, but sounds to me
it's going the same problem as gtk2hs on windows.

One better way, would be to tap in the 2, work in progress, gnupg haskell
replacement:

http://hackage.haskell.org/**package/openpgp
http://hackage.haskell.org/**package/hOpenPGP

AFAIK, both packages are not yet handling anything related to WoT, but
just do the signing/verification (which is same status as my ad-hoc
experiment)



In this case I think this is the wrong approach.  There must be at least
one way to work within a trust model that is not fragile.  Whether this is
fully supported on all platforms is actually not very important.

I have pointed out why simply signing packages is fragile and how git is
better suited for this task.  We are not going to reimplement all the good
infrastructure that already exists (gpg, git), so making that a requirement
is not a good idea IMO.

Basic verification of signatures should work on Windows, I agree.  But the
underlying WoT should be a little bit more sophisticated.  This means it
has to be based on standard tools, or it will never happen.


I think you misunderstood me.

Having a fully working pgp package, means you have full control of the 
pgp stack, you don't rely on hard-to-get out tools, and it can be 
integrated with cabal directly for a full WoT experience.


Also git doesn't solve the hackage problem, there's not necessarily a 
one-to-one mapping between packages and their repositories.


--
Vincent

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Vincent Hanquez]

On 01/31/2013 10:06 AM, Ertugrul Söylemez wrote:

Joachim Breitner  wrote:


And that may even be more harmful, because an insecure system with a
false sense of security is worse than an insecure system alone.

Let's do it properly.

but don’t overengineer it either. Simply adding to hackage the
possibility to store a .asc file next to the tar.gz file that contains
the cryptographic signature would be a great start, and allow us to
develop a WoT model later on.

(I try to resist from wondering whether this could go into hackage1 or
only hackage2, and in the latter case, whether that means that we
actually have the time to overengineer the system.)

In fact, a lot would already be gained by a simple „warn if foo-2.0 is
signed with a different key than the version of foo already installed“
on cabal-install and people having a closer look at uploads from
different people. Not much infrastructure needed there.

That was exactly my suggestion actually.  It requires the ability to
make and check signatures.  The making can be done with external tools
like GnuPG, but the checking has to be done by cabal-install.  To detect
changed keys there also needs to be a trust database, which can be a
simple directory in ~/.cabal/ where files are named after the
fingerprint of the key it contains.

The most important part is a sensible user interface.  The whole process
should be invisible to the user, until there is a signature error.  The
first installation of a package will actually generate a handful of
signature errors, because the keys are not known yet.

This shouldn't be too hard to implement and requires only a small change
to Hackage and cabal-install's upload command to begin.


That's not a proper solution, and definitively in the warm fuzzy feeling 
department.


What if you install a package for the first time and this package has 
just been re-uploaded maliciously with a different key and a payload ?
What if you're relying on hackage mirrors, what stop this mirror to 
regenerate all signatures with a new key ?


It also make maintainers change difficult, and doing genuine 
non-maintainer upload.


--
Vincent

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Ertugrul Söylemez]

Joachim Breitner  wrote:

> > And that may even be more harmful, because an insecure system with a
> > false sense of security is worse than an insecure system alone.
> >
> > Let's do it properly.
>
> but don’t overengineer it either. Simply adding to hackage the
> possibility to store a .asc file next to the tar.gz file that contains
> the cryptographic signature would be a great start, and allow us to
> develop a WoT model later on.
>
> (I try to resist from wondering whether this could go into hackage1 or
> only hackage2, and in the latter case, whether that means that we
> actually have the time to overengineer the system.)
>
> In fact, a lot would already be gained by a simple „warn if foo-2.0 is
> signed with a different key than the version of foo already installed“
> on cabal-install and people having a closer look at uploads from
> different people. Not much infrastructure needed there.

That was exactly my suggestion actually.  It requires the ability to
make and check signatures.  The making can be done with external tools
like GnuPG, but the checking has to be done by cabal-install.  To detect
changed keys there also needs to be a trust database, which can be a
simple directory in ~/.cabal/ where files are named after the
fingerprint of the key it contains.

The most important part is a sensible user interface.  The whole process
should be invisible to the user, until there is a signature error.  The
first installation of a package will actually generate a handful of
signature errors, because the keys are not known yet.

This shouldn't be too hard to implement and requires only a small change
to Hackage and cabal-install's upload command to begin.


Greets,
Ertugrul

-- 
Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.


signature.asc
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Joachim Breitner]

Hi,

Am Donnerstag, den 31.01.2013, 09:42 +0100 schrieb Ertugrul Söylemez:
> And that may even be more harmful, because an insecure system with a
> false sense of security is worse than an insecure system alone.
> 
> Let's do it properly.

but don’t overengineer it either. Simply adding to hackage the
possibility to store a .asc file next to the tar.gz file that contains
the cryptographic signature would be a great start, and allow us to
develop a WoT model later on.

(I try to resist from wondering whether this could go into hackage1 or
only hackage2, and in the latter case, whether that means that we
actually have the time to overengineer the system.)

In fact, a lot would already be gained by a simple „warn if foo-2.0 is
signed with a different key than the version of foo already installed“
on cabal-install and people having a closer look at uploads from
different people. Not much infrastructure needed there.

Greetings,
Joachim


-- 
Joachim "nomeata" Breitner
  m...@joachim-breitner.de  |  nome...@debian.org  |  GPG: 0x4743206C
  xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/



signature.asc
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Ramana Kumar]

On Thu, Jan 31, 2013 at 8:16 AM, Ketil Malde  wrote:

>
> Ertugrul Söylemez  writes:
>
> > People are using Hackage!
>
> +1. And I keep telling people to use it.  Sure, it'd be better if they
> used .debs, .rpms, or whatever goes on Mac and Windows.  But that would
> mean I would need to build those packages, including maintaining systems
> with the respective OSes.  I haven't even managed to do it for the
> systems I do use.
>

Some people seem to have been confused that by suggesting that cabal is not
a package manager, I was suggesting not to use Hackage or cabal at all, or
not to bother signing packages.
To be clear, I am for the following:

   - Using Hackage (for storing packages, searching online, downloading to
   create OS packages)
   - Using cabal (as a package developer, for testing/creating/uploading
   packages)
   - Signing packages on Hackage - this is important for security, and I
   don't want to detract further from the discussion about how to do it.

What I am against is:

   - Using cabal to "install" packages and generally as a package manager
   (e.g. try to use it to delete or upgrade packages).

This often ends in tears, because that is not cabal's job and it doesn't do
it well! Rather, you should help whoever is making packages for your OS (or
start doing this) by packaging the existing "cabal packages" on Hackage as
proper OS packages suitable for install/upgrade/remove etc. This can be
largely automated, and the main headaches come from dependency issues,
which are a separate problem on Hackage (and which Stackage is aiming to
alleviate).
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Alexander Kjeldaas]

On Thu, Jan 31, 2013 at 9:26 AM, Vincent Hanquez  wrote:

> On 01/31/2013 06:27 AM, Ertugrul Söylemez wrote:
>
>> In any case there is no valid excuse for the lack of crypto.  It's too
>> easy to attack Hackage, so we need some crypto regardless of what we
>> interpret it as.
>>
>> My proposal is:
>>
>>1. Build the necessary machinery into Cabal to allow signing keys and
>>   packages and verifying the signatures, ideally through GnuPG.
>>   Cabal would benefit from that even without cabal-install and
>>   Hackage.
>>
>
> Seems there's lots of suggestion of using gnupg, which is a perfectly
> valid answer if cabal was unix only, but i'm not sure it's a valid option
> considering windows. Sure you can install gnupg somehow, but sounds to me
> it's going the same problem as gtk2hs on windows.
>
> One better way, would be to tap in the 2, work in progress, gnupg haskell
> replacement:
>
> http://hackage.haskell.org/**package/openpgp
> http://hackage.haskell.org/**package/hOpenPGP
>
> AFAIK, both packages are not yet handling anything related to WoT, but
> just do the signing/verification (which is same status as my ad-hoc
> experiment)
>
>
In this case I think this is the wrong approach.  There must be at least
one way to work within a trust model that is not fragile.  Whether this is
fully supported on all platforms is actually not very important.

I have pointed out why simply signing packages is fragile and how git is
better suited for this task.  We are not going to reimplement all the good
infrastructure that already exists (gpg, git), so making that a requirement
is not a good idea IMO.

Basic verification of signatures should work on Windows, I agree.  But the
underlying WoT should be a little bit more sophisticated.  This means it
has to be based on standard tools, or it will never happen.

Alexander

>
>
> __**_
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/**mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Ertugrul Söylemez]

Vincent Hanquez  wrote:

> For example, previous maintainer might be away from email for a long
> time potentially leaving a trojan version for days/weeks, or changed
> email address..

And that may even be more harmful, because an insecure system with a
false sense of security is worse than an insecure system alone.

Let's do it properly.


Greets,
Ertugrul

-- 
Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.


signature.asc
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Ertugrul Söylemez]

Vincent Hanquez  wrote:

> I agree this is terrible, I've started working on this, but this is
> quite a bit of work and other priorities always pop up.
>
> https://github.com/vincenthz/cabal
> https://github.com/vincenthz/cabal-signature
>
> My current implementation generate a manifest during sdist'ing in
> cabal, and have cabal-signature called by cabal on the manifest to
> create a manifest.sign.
>
> The main issue i'm facing is how to create a Web of Trust for doing
> all the public verification bits.

You don't need it yet.  See my other post.  Once the basic
infrastructure for signatures is established, you can allow the user to
have a set of trusted keys.  The idea is that users can ask for keys
and/or import keys from key servers.  In the worst case they accept keys
when installing a package.  Once you have such a trust database you can
allow users to select, whether a key is to be trusted for signing other
keys.  Then you have basically everything to establish both hierarchial
trust relationships (like CAs) and webs of trust.


Greets,
Ertugrul

-- 
Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.


signature.asc
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Vincent Hanquez]

On 01/31/2013 08:16 AM, Ketil Malde wrote:

*MY* proposal is that:

0. Hackage sends an email to the previous uploader whenever a new
version of a package is uploaded by somebody else.

At least that way, I would be notified if it happened to my packages,
and I would be able to check up on the situation, and rectify it.

you wouldn't in real cases, it just fix the most obvious and simple 
attack vector. but consider:


* someone intercepting your upload http stream, and replacing 
dynamically your package.
* someone gaining malicious access to hackage and planting stuff inside 
packages.

* a rogue hackage admin.
* a rogue hackage mirror admin.

it's obviously less easy than just creating an account and uploading 
things on top of other packages, but i don't think we should feel safe 
if the previous maintainer received an email about the change. For 
example, previous maintainer might be away from email for a long time 
potentially leaving a trojan version for days/weeks, or changed email 
address..


--
Vincent

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Vincent Hanquez]

On 01/31/2013 06:27 AM, Ertugrul Söylemez wrote:

In any case there is no valid excuse for the lack of crypto.  It's too
easy to attack Hackage, so we need some crypto regardless of what we
interpret it as.

My proposal is:

   1. Build the necessary machinery into Cabal to allow signing keys and
  packages and verifying the signatures, ideally through GnuPG.
  Cabal would benefit from that even without cabal-install and
  Hackage.


Seems there's lots of suggestion of using gnupg, which is a perfectly 
valid answer if cabal was unix only, but i'm not sure it's a valid 
option considering windows. Sure you can install gnupg somehow, but 
sounds to me it's going the same problem as gtk2hs on windows.


One better way, would be to tap in the 2, work in progress, gnupg 
haskell replacement:


http://hackage.haskell.org/package/openpgp
http://hackage.haskell.org/package/hOpenPGP

AFAIK, both packages are not yet handling anything related to WoT, but 
just do the signing/verification (which is same status as my ad-hoc 
experiment)


--
Vincent

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Joachim Breitner]

Hi,

Am Mittwoch, den 30.01.2013, 15:07 -0800 schrieb Edward Z. Yang:
> Nevertheless, I believe we are in violent agreement that
> cryptographically signed Hackage packages should happen as soon as
> possible!

I don’t think we need hackage support here. Just add a "MD5-Sum:" field
to the .cabal file specifying the checksum of the resulting tarball, and
everyone can just check it after downloading. At least with MD5 and
modern computers, this should be possible by now or soon.

(SCNR)

Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


signature.asc
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Ketil Malde]

Ertugrul Söylemez  writes:

> People are using Hackage!

+1. And I keep telling people to use it.  Sure, it'd be better if they
used .debs, .rpms, or whatever goes on Mac and Windows.  But that would
mean I would need to build those packages, including maintaining systems
with the respective OSes.  I haven't even managed to do it for the
systems I do use.

The most simple and obvious threat is here that some random evil person
gets a Hackage account, uploads a new version of a common package with a
trojan, and waits for unsuspecting users to download and install it.

> My proposal is:
>
>   1. Build the necessary machinery into Cabal to allow signing [...]

*MY* proposal is that:

0. Hackage sends an email to the previous uploader whenever a new
   version of a package is uploaded by somebody else.

At least that way, I would be notified if it happened to my packages,
and I would be able to check up on the situation, and rectify it.

This is not to say that cryptographic signing is the wrong thing to do,
but a very simple thing like this, which would probably take all of five
minutes to implement, would reduce risk by a substantial amount.

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Vincent Hanquez]

On 01/30/2013 10:48 PM, Niklas Hambüchen wrote:

You are right, I skipped over that this was actually a server-side
exploit - sure, end-to-end signing will help here.

it helps also in the HTTP case; a MiTM wouldn't be able to change the 
package without knowing the private key.
more to the point it also help the case with hackage mirrors (or a 
corrupt hackage admin).


--
Vincent

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Vincent Hanquez]

On 01/30/2013 07:27 PM, Edward Z. Yang wrote:

https://status.heroku.com/incidents/489

Unsigned Hackage packages are a ticking time bomb.

I agree this is terrible, I've started working on this, but this is 
quite a bit of work and other priorities always pop up.


https://github.com/vincenthz/cabal
https://github.com/vincenthz/cabal-signature

My current implementation generate a manifest during sdist'ing in cabal, 
and have cabal-signature called by cabal on the manifest to create a 
manifest.sign.


The main issue i'm facing is how to create a Web of Trust for doing all 
the public verification bits.


--
Vincent

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Alexander Kjeldaas]

Not to downplay the significance of this issue,  but a primary issue, much
more important is to secure ghc, base, cabal-install, and the build process
for these.
The development process needs to be robust.

That process should include signing commits by *two developers*.  This is
really not a lot of work as a code-review is already done, but more
significantly helps fend off a lot of compromised repository issues.

There are just a few simple rules to follow:  Review the commit on your own
equipment, and sign it.  That way an attacker will have to compromise two
physically different repositories.

.http://mikegerwitz.com/docs/git-horror-story.html

This is a change that doesn't need any new development, just a procedure
change.

Wrt Hackage, simply signing packages is going to improve things, but what
would be way more awesome would be to have multiple people sign off on the
difference between two releases.

What I mean is that whenever somebody reviews a new release of some package
(the diff from a previous release), the work they did should ideally be
represented as a signature on that release, or the "commit" that is the
diff between the two releases.  Git can handle this sort of trust issues,
but a simple signature scheme will not.

Now if a large security-conscious corporation starts using packages from
Hackage, they will already have a security team that does code reviews.
 With a simple signature scheme, the output from their security team will
not be possible to use on Hackage.

I for one would be much more likely to trust packages signed by the
signature by someone who has found numerous security flaws in various
packages on Hackage, than some random developer.  One signature might mean
"this is my release, if you trust my machine,repository, +++". Another
signature might mean "the security team of X Corp has done a security
review at level Y.  This is cleared for production use.".  Simply
supporting the first signature is no good.

So if we really want to fix this, I suggest moving a large part of the
trust infrastructure off of hackage and into git or similar systems that
have better support for dealing with trust.

Alexander


On Wed, Jan 30, 2013 at 8:27 PM, Edward Z. Yang  wrote:

> https://status.heroku.com/incidents/489
>
> Unsigned Hackage packages are a ticking time bomb.
>
> Cheers,
> Edward
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Ertugrul Söylemez]

Ramana Kumar  wrote:

> But if you keep calling cabal a package manager, eventually you'll
> have to write the patches to make it one.

The combination of Cabal, cabal-install and Hackage is a package
distribution system.  As such, it needs the necessary cryptographic
support.  I don't view them as a package management system.

What's important is that many programmers blindly trust the code they
download, install and run from Hackage.  Yes, it's a bad habit, but
seriously, that's the alternative?  Distributions are often some linear
combination of outdated and broken with coefficients near 1.  Let me
restate the important fact with more emphasis:

People are using Hackage!

In any case there is no valid excuse for the lack of crypto.  It's too
easy to attack Hackage, so we need some crypto regardless of what we
interpret it as.

My proposal is:

  1. Build the necessary machinery into Cabal to allow signing keys and
 packages and verifying the signatures, ideally through GnuPG.
 Cabal would benefit from that even without cabal-install and
 Hackage.

  2. Update Hackage to allow uploading signatures along with packages.

  3. Update cabal-install to allow signing packages and optionally
 checking the signatures.  Do not allow signature chains.  Do not
 support CAs for now.

 Have a database of trusted keys.  Could be a directory below
 ~/.cabal with keys as files.

 More detailed (skip to next step, if you're not going to implement
 this):  Before installing anything, build a map from maintainers
 from whom we would be installing packages to the packages they
 maintain.  Maintainers are identified by their keys, not their
 usernames.  If any of the keys is not trusted yet, then print this
 list as readable as possible.  Use colors, etc.  Hypothetical
 example:

 % cabal install diagrams
 Resolving dependencies...
 The following maintainers are untrusted:

 Diagrams Project <...@...> [ABCD1234]:
 FP:           
 monoid-extras-0.2.2.2
 dual-tree-0.1.0.1
 diagrams-core-0.6.0.1
 diagrams-lib-0.6.0.1
 diagrams-svg-0.6.0.1
 diagrams-contrib-0.6.0.1
 diagrams-0.6

 Trust them (?/y/n/t)? ?
   y: yes
   n: no (default)
   t: temporarily

 Trust them (?/y/n/t)? y
 Adding to trust db: Diagrams Project <...@...> [ABCD1234]

 [install]

 Cabal should ignore the "Maintainer" field in the Cabal file.  Only
 the signature counts here.  Cabal must report a changed maintainer:

 % cabal install diagrams
 Resolving dependencies...
 WARNING: Package 'diagrams-core' has changed maintainer.
 [old key info]
 [new key info]
 Install anyway (y/n)? y
 The following maintainers are untrusted:

 [...]

  4. Announce the change and urge maintainers to update their packages
 to include signatures.

  5. Wait a few weeks.

  6. Make signature verification the default in cabal-install.

  7. Optionally implement CA support and establish a CA outside and
 offsite of Hackage.  Someone with a good understanding of server
 security and cryptography should do that.  They could be added to
 ~/.cabal/config to make package installations easier.

Steps 1..6 should be done with high priority, otherwise they will never
be finished.  Step 7 is optional.  If you're indeed considering this,
I'm happy to turn this into a set of bug tracker issues and possibly
help with the development.


Greets,
Ertugrul

-- 
Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.


signature.asc
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Edward Z. Yang]

Excerpts from Joachim Breitner's message of Wed Jan 30 14:57:28 -0800 2013:
> I’m not against cryptographically signed packages on hackage. In fact, I
> would whole-heatedly appreciate it, as it would make my work as a
> package maintainer easier.
> 
> I was taking the opportunity to point out an advantage of established
> package management systems, to shamelessly advertise my work there, as
> not everyone sees distro-packaged libraries as a useful thing.

Yes. In fact, I am a sysadmin for a large shared hosting environment, and
the fact that programming language libraries tend not to be distro-packaged
is an endless headache for us.  We would like it if everything were just
packaged properly!

On the other hand, working in these circumstances has made me realize
that there is a huge tension between the goals of package library
authors and distribution managers (a package library author is desires
ease of installation of their packages, keeping everyone up-to-date as
possible and tends to be selfish when it comes to the rest of the
ecosystem, whereas the distribution manager values stability, security,
and global consistency of the ecosystem.)  So there is a lot of work to
be done here.  Nevertheless, I believe we are in violent agreement that
cryptographically signed Hackage packages should happen as soon as
possible!

Edward

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Joachim Breitner]

Hi,

Am Mittwoch, den 30.01.2013, 14:43 -0800 schrieb Edward Z. Yang:
> Excerpts from Joachim Breitner's message of Wed Jan 30 12:59:48 -0800 2013:
> > another reason why Cabal is no package manager¹.
> 
> Based on the linked post, it seems that you are arguing that cabal-install is
> not a package manager, and thus it is not necessary for it to duplicate
> the work that real package managers e.g. Debian or Ubuntu put into
> vetting, signing and releasing software.  (Though I am not sure, so please
> correct me if I am wrong.)

I’m not against cryptographically signed packages on hackage. In fact, I
would whole-heatedly appreciate it, as it would make my work as a
package maintainer easier.

I was taking the opportunity to point out an advantage of established
package management systems, to shamelessly advertise my work there, as
not everyone sees distro-packaged libraries as a useful thing.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


signature.asc
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Ramana Kumar]

On Wed, Jan 30, 2013 at 10:48 PM, Edward Z. Yang  wrote:

> Excerpts from Ramana Kumar's message of Wed Jan 30 14:46:26 -0800 2013:
> > > This argument seems specious.  Whether or not cabal-install is or not
> > > intended to be a package manager, users expect it to act like one (as
> > > users expect rubygems to be a package manager), and, at the end of the
> > > day, that is what matters.
> > >
> >
> > But playing along with their delusion might make it harder to change
> their
> > minds.
>
> Looking at the library ecosystems of the most popular programming
> languages,
> I think this ship has already sailed.
>

I was talking only about Haskell and cabal.
There is a viable alternative to using cabal as a package manager on Arch
Linux (the Arch-Haskell package repositories).
There is also the Stackage project that might make this possible on more
distributions with real package managers.
But if you keep calling cabal a package manager, eventually you'll have to
write the patches to make it one.


>
> Edward
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Edward Z. Yang]

Excerpts from Ramana Kumar's message of Wed Jan 30 14:46:26 -0800 2013:
> > This argument seems specious.  Whether or not cabal-install is or not
> > intended to be a package manager, users expect it to act like one (as
> > users expect rubygems to be a package manager), and, at the end of the
> > day, that is what matters.
> >
> 
> But playing along with their delusion might make it harder to change their
> minds.

Looking at the library ecosystems of the most popular programming languages,
I think this ship has already sailed.

Edward

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Niklas Hambüchen]

You are right, I skipped over that this was actually a server-side
exploit - sure, end-to-end signing will help here.

On 30/01/13 19:47, Edward Z. Yang wrote:
>> As long as we upload packages via plain HTTP, signing won't help though.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Ramana Kumar]

On Wed, Jan 30, 2013 at 10:43 PM, Edward Z. Yang  wrote:

> This argument seems specious.  Whether or not cabal-install is or not
> intended to be a package manager, users expect it to act like one (as
> users expect rubygems to be a package manager), and, at the end of the
> day, that is what matters.
>

But playing along with their delusion might make it harder to change their
minds.


>
> Edward
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Edward Z. Yang]

Excerpts from Joachim Breitner's message of Wed Jan 30 12:59:48 -0800 2013:
> another reason why Cabal is no package manager¹.

Based on the linked post, it seems that you are arguing that cabal-install is
not a package manager, and thus it is not necessary for it to duplicate
the work that real package managers e.g. Debian or Ubuntu put into
vetting, signing and releasing software.  (Though I am not sure, so please
correct me if I am wrong.)

This argument seems specious.  Whether or not cabal-install is or not
intended to be a package manager, users expect it to act like one (as
users expect rubygems to be a package manager), and, at the end of the
day, that is what matters.

Edward

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Felipe Almeida Lessa]

IMHO Hackage and Cabal should support package signing even if they
aren't package managers.

On Wed, Jan 30, 2013 at 6:59 PM, Joachim Breitner  wrote:
> Hi,
>
> Am Mittwoch, den 30.01.2013, 11:27 -0800 schrieb Edward Z. Yang:
>> https://status.heroku.com/incidents/489
>>
>> Unsigned Hackage packages are a ticking time bomb.
>
> another reason why Cabal is no package manager¹.
>
> (Ok, I admit that I don’t review every line of diff between the Haskell
> packages I uploads. But thanks to http://hdiff.luite.com/ I at least
> glance over them most of the time – a hurdle that malicious code would
> have to take. And once a package has entered a distribution like Debian
> (which it only can with a valid cryptographic signatures), checksums and
> signatures are used in many places to (mostly) guarantee that the
> package reaches the user unmodified.)
>
> Greetings,
> Joachim
>
> ¹ 
> http://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager/
>
> --
> Joachim "nomeata" Breitner
> Debian Developer
>   nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
>   JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
Felipe.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Joachim Breitner]

Hi,

Am Mittwoch, den 30.01.2013, 11:27 -0800 schrieb Edward Z. Yang:
> https://status.heroku.com/incidents/489
> 
> Unsigned Hackage packages are a ticking time bomb.

another reason why Cabal is no package manager¹.

(Ok, I admit that I don’t review every line of diff between the Haskell
packages I uploads. But thanks to http://hdiff.luite.com/ I at least
glance over them most of the time – a hurdle that malicious code would
have to take. And once a package has entered a distribution like Debian
(which it only can with a valid cryptographic signatures), checksums and
signatures are used in many places to (mostly) guarantee that the
package reaches the user unmodified.)

Greetings,
Joachim

¹ 
http://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager/

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


signature.asc
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Bob Ippolito]

HTTPS doesn't really change anything if the server is compromised, it only
prevents bad things from happening in transit.

Sign the packages with GPG (or equivalent) before upload. The server never
sees the package author's private key, only the public key. Server and/or
client can warn or fail if the public key doesn't match their previous
credentials or the signature verification fails.


On Wed, Jan 30, 2013 at 11:44 AM, Niklas Hambüchen  wrote:

> As long as we upload packages via plain HTTP, signing won't help though.
>
> On Wed 30 Jan 2013 19:27:32 GMT, Edward Z. Yang wrote:
> > https://status.heroku.com/incidents/489
> >
> > Unsigned Hackage packages are a ticking time bomb.
> >
> > Cheers,
> > Edward
> >
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Edward Z. Yang]

> As long as we upload packages via plain HTTP, signing won't help though.

I don't think that's true?  If the package is tampered with, then the
signature will be invalid; if the signature is also forged, then the
private key is compromised and we can blacklist it.  We care only
about integrity, not secrecy.

Edward

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Niklas Hambüchen]

As long as we upload packages via plain HTTP, signing won't help though.

On Wed 30 Jan 2013 19:27:32 GMT, Edward Z. Yang wrote:
> https://status.heroku.com/incidents/489
>
> Unsigned Hackage packages are a ticking time bomb.
>
> Cheers,
> Edward
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe