Quantcast

Package security in stack

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Package security in stack

Michael Snoyman
Since a lot of the discussions around package security happened on this list- and likely concern its audience- I thought it would be appropriate to let everyone know about the following blog post:

https://www.fpcomplete.com/blog/2015/07/package-security-in-stack

It covers the package security implementation present in the stack build tool.

--
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Package security in stack

Nikita Karetnikov
> Since a lot of the discussions around package security happened on this
> list- and likely concern its audience- I thought it would be appropriate to
> let everyone know about the following blog post:
>
> https://www.fpcomplete.com/blog/2015/07/package-security-in-stack
>
> It covers the package security implementation present in the stack build
> tool.

Thanks for writing this up!  Just to be sure, does it mean that only
packages are being checked?  What about GHC tarballs?

--






signature.asc (834 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Package security in stack

Nikita Karetnikov
Oh, one more thing.  Are there any plans to make this information
(hashes and signatures) visible to end users?  Would be nice to be able
to ask stack about the hash of an installed package.

--






signature.asc (834 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Package security in stack

Michael Snoyman

GHC tarballs are not currently being checked, but they should be, and it's not difficult to add (the underlying download mechanism has support, we just need to add the SHAs to the metadata file[1] and wire up a few things in the stack codebase. Can you open an issue about this so it isn't lost?

There aren't any plans about making this visible to end users, I'm not quite sure what that would look like. Could you clarify?

[1] https://github.com/fpco/stackage-content/blob/master/stack/stack-setup.yaml


On Mon, Jul 20, 2015, 8:17 AM Nikita Karetnikov <[hidden email]> wrote:
Oh, one more thing.  Are there any plans to make this information
(hashes and signatures) visible to end users?  Would be nice to be able
to ask stack about the hash of an installed package.

--

--
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Package security in stack

Christopher Reichert
In reply to this post by Michael Snoyman


This is great news, I've integrated the configuration into our builds.
and I'm excited to hear about progress on the author package signing as
well.

-Christopher

On Mon, Jul 20 2015, Michael Snoyman <[hidden email]> wrote:
> Since a lot of the discussions around package security happened on this
> list- and likely concern its audience- I thought it would be appropriate to
> let everyone know about the following blog post:
>
> https://www.fpcomplete.com/blog/2015/07/package-security-in-stack
>
> It covers the package security implementation present in the stack build
> tool.


--
Christopher Reichert
irc: creichert
gpg: C81D 18C8 862A 3618 1376  FFA5 6BFC A992 9955 929B

--






signature.asc (834 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Package security in stack

Nikita Karetnikov
In reply to this post by Michael Snoyman
> GHC tarballs are not currently being checked, but they should be, and it's
> not difficult to add (the underlying download mechanism has support, we
> just need to add the SHAs to the metadata file[1] and wire up a few things
> in the stack codebase. Can you open an issue about this so it isn't lost?

https://github.com/commercialhaskell/stack/issues/637

> There aren't any plans about making this visible to end users, I'm not
> quite sure what that would look like. Could you clarify?

I haven't thought about it much, but it might be useful to compare
hashes.  E.g., a stack user and a cabal-install user could verify that
they got the exact same package.  Same for signatures.  It might come in
handy when hash verification fails.  Not sure whether it's a high
priority, just thinking out loud since having more information/tools is
almost always better than the opposite.

--






signature.asc (834 bytes) Download Attachment
Loading...