Marc Weber marco-owe...@gmx.de 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
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
+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
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
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
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
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
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
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.
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
Ertugrul Söylemez e...@ertes.de 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
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
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
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
Vincent Hanquez t...@snarc.org 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
Vincent Hanquez t...@snarc.org 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
On Thu, Jan 31, 2013 at 9:26 AM, Vincent Hanquez t...@snarc.org 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
On Thu, Jan 31, 2013 at 8:16 AM, Ketil Malde ke...@malde.org wrote:
Ertugrul Söylemez e...@ertes.de 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
Joachim Breitner m...@joachim-breitner.de 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
On 01/31/2013 10:06 AM, Ertugrul Söylemez wrote:
Joachim Breitner m...@joachim-breitner.de 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.
On 01/31/2013 08:54 AM, Alexander Kjeldaas wrote:
On Thu, Jan 31, 2013 at 9:26 AM, Vincent Hanquez t...@snarc.org 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
Vincent Hanquez t...@snarc.org 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
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
On Thu, Jan 31, 2013 at 11:48 AM, Vincent Hanquez t...@snarc.org wrote:
On 01/31/2013 08:54 AM, Alexander Kjeldaas wrote:
On Thu, Jan 31, 2013 at 9:26 AM, Vincent Hanquez t...@snarc.org wrote:
On 01/31/2013 06:27 AM, Ertugrul Söylemez wrote:
In any case there is no valid excuse for the
Vincent Hanquez t...@snarc.org 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
On Thu, Jan 31, 2013 at 11:40 AM, Vincent Hanquez t...@snarc.org wrote:
On 01/31/2013 10:06 AM, Ertugrul Söylemez wrote:
Joachim Breitner m...@joachim-breitner.de wrote:
And that may even be more harmful, because an insecure system with a
false sense of security is worse than an insecure
Ertugrul Söylemez e...@ertes.de 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
On Thu, Jan 31, 2013 at 12:53 PM, Ketil Malde ke...@malde.org wrote:
Ertugrul Söylemez e...@ertes.de 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
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:
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
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
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
___
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,
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
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
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 nome...@debian.org wrote:
Hi,
Am Mittwoch, den 30.01.2013, 11:27 -0800 schrieb Edward Z. Yang:
https://status.heroku.com/incidents/489
Unsigned
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
On Wed, Jan 30, 2013 at 10:43 PM, Edward Z. Yang ezy...@mit.edu 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
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
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,
On Wed, Jan 30, 2013 at 10:48 PM, Edward Z. Yang ezy...@mit.edu 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
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
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
Ramana Kumar ramana.ku...@cl.cam.ac.uk 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
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
45 matches
Mail list logo
