As the CLiki recent changes page shows:
http://www.cliki.net/Recent%20Changes
the site was massively spammed. Something similar happened to the ALU
Wiki site:
http://wiki.alu.org/Special:RecentChanges
but content seems to have been restored. Here is a message to the CL
Gardeners list explaining what happened to the ALU Wiki site:
Can anyone tell what's going on on the ALU Wiki?
http://www.lispniks.com/pipermail/gardeners/2006-January/000925.html
These attacks raise some issues on the safety of links used for
ASDF-INSTALL.
Paolo
--
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
From: Christophe Rhodes
Subject: Re: CLiki and ALU Wiki sites massively spammed
Date:
Message-ID: <sq8xt7z3op.fsf@cam.ac.uk>
Paolo Amoroso <·······@mclink.it> writes:
> These attacks raise some issues on the safety of links used for
> ASDF-INSTALL.
This is a good reason not to blindly disable or ignore the gpg
checking for software downloaded using asdf-install.
Christophe
Christophe Rhodes <·····@cam.ac.uk> writes:
> Paolo Amoroso <·······@mclink.it> writes:
>
> > These attacks raise some issues on the safety of links used for
> > ASDF-INSTALL.
>
> This is a good reason not to blindly disable or ignore the gpg
> checking for software downloaded using asdf-install.
That's true, but I suspect that as more and more people use
asdf-install, the there will be an increase in people who don't look
at the link something comes from, and don't or can't check the
signatures. An additional safety net would be a good thing: say, a
1-3 day delay from when an asdf-install link is edited to its
becoming visible, and a seperate changes feed for asdf-install links.
(Damn, I get the feeling I just volunteered myself)
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
From: Bill Atkins
Subject: Re: CLiki and ALU Wiki sites massively spammed
Date:
Message-ID: <87fynfqb7r.fsf@rpi.edu>
Christophe Rhodes <·····@cam.ac.uk> writes:
> Paolo Amoroso <·······@mclink.it> writes:
>
>> These attacks raise some issues on the safety of links used for
>> ASDF-INSTALL.
>
> This is a good reason not to blindly disable or ignore the gpg
> checking for software downloaded using asdf-install.
>
> Christophe
Still, it seems like pulling the addresses from a wiki is just asking
for trouble. What would be the problem (aside from finding someone to
do it) with running a dedicated server (a la CPAN) from which
ASDF-INSTALL could pull links? There is the issue of being able to
trust the people who decide what links go in, but that seems like an
easier thing to do than to trust a wiki.
--
Bill Atkins
From: Christophe Rhodes
Subject: Re: CLiki and ALU Wiki sites massively spammed
Date:
Message-ID: <sqd5ijxax3.fsf@cam.ac.uk>
Bill Atkins <············@rpi.edu> writes:
> Christophe Rhodes <·····@cam.ac.uk> writes:
>
>> This is a good reason not to blindly disable or ignore the gpg
>> checking for software downloaded using asdf-install.
>
> Still, it seems like pulling the addresses from a wiki is just asking
> for trouble. What would be the problem (aside from finding someone to
> do it) with running a dedicated server (a la CPAN) from which
> ASDF-INSTALL could pull links? There is the issue of being able to
> trust the people who decide what links go in, but that seems like an
> easier thing to do than to trust a wiki.
Right, which is why asdf-install does not trust the wiki. Instead, it
asks you to trust library authors.
With a centralised scheme, you would have to trust
* the maintainer of the links, and
* the individual library authors
unless of course you think that the maintainer of the links should be
doing source code auditing, in which case you have to trust the
maintainer of the links an awful lot, and also that the host they're
using is safe from compromise, and that your DNS hasn't been hit by
spoofing, and any of a number of other scenarios.
With a wiki-like scheme, you have to trust
* the individual library authors
and no-one else.
I fail to see any security advantage at all from a centralised scheme.
Christophe
Christophe Rhodes wrote:
> Right, which is why asdf-install does not trust the wiki. Instead, it
> asks you to trust library authors.
It asks you to trust _Wiki authors_, who may not be the library
authors.
I conducted an informal and limited survey of CLiki packages and found
that not all packages have .asc files anyway. trivial-https and cl-sdl,
for example, show no signs of having an obtainable .asc file, and if I
were to replace their links with a link to a compromised package on my
host, adsf-install wouldn't help in distinguishing my keyless package
from the official keyless package.
> With a centralised scheme, you would have to trust
> * the maintainer of the links, and
> * the individual library authors
> unless of course you think that the maintainer of the links should be
> doing source code auditing, in which case you have to trust the
> maintainer of the links an awful lot, and also that the host they're
> using is safe from compromise, and that your DNS hasn't been hit by
> spoofing, and any of a number of other scenarios.
>
> With a wiki-like scheme, you have to trust
> * the individual library authors
> and no-one else.
Assuming that the host they're using is safe from compromise, that your
DNS hasn't been hit by spoofing, and any of a number of other
scenarios.
> I fail to see any security advantage at all from a centralised scheme.
If the link maintainer _is_ auditing the source code, then there's an
obvious advantage. Not that I'm not volunteering to audit CLiki
packages. I wouldn't know how anyway.
> Christophe
From: Christophe Rhodes
Subject: Re: CLiki and ALU Wiki sites massively spammed
Date:
Message-ID: <sqek2yzuu4.fsf@cam.ac.uk>
"Nathan Baum" <···········@btinternet.com> writes:
> Christophe Rhodes wrote:
>> Right, which is why asdf-install does not trust the wiki. Instead, it
>> asks you to trust library authors.
>
> It asks you to trust _Wiki authors_, who may not be the library
> authors.
No, it doesn't.
> I conducted an informal and limited survey of CLiki packages and found
> that not all packages have .asc files anyway. trivial-https and cl-sdl,
> for example, show no signs of having an obtainable .asc file, and if I
> were to replace their links with a link to a compromised package on my
> host, adsf-install wouldn't help in distinguishing my keyless package
> from the official keyless package.
That is true. (You mean signatureless). So don't use signatureless
packages. (At least not without validating their contents yourself)
>> With a wiki-like scheme, you have to trust
>> * the individual library authors
>> and no-one else.
>
> Assuming that the host they're using is safe from compromise, that your
> DNS hasn't been hit by spoofing, and any of a number of other
> scenarios.
No. If my DNS has been hit by spoofing or the host they use is
compromised, and I download a package that is signed by someone not in
my trust ring (or not signed at all), then the system will have done
its job: it will have alerted me to the fact that a package might not
be what it seems. It is true that this relies on authors not being
terribly stupid with their gpg private keys, and also on some minimal
physical connection with the PGP Web of Trust, but it in no way relies
on the integrity of any internet host.
Christophe
Christophe Rhodes <·····@cam.ac.uk> writes:
> No. If my DNS has been hit by spoofing or the host they use is
> compromised, and I download a package that is signed by someone not in
> my trust ring (or not signed at all), then the system will have done
> its job: it will have alerted me to the fact that a package might not
> be what it seems. It is true that this relies on authors not being
> terribly stupid with their gpg private keys, and also on some minimal
> physical connection with the PGP Web of Trust, but it in no way relies
> on the integrity of any internet host.
Some web of trust connection is a plus, I guess, but it's really
unnecessary. I got to meet Dan Barlow face-to-face for the first time
at the last European Lisp Meeting, when he was distributing his new
PGP key. I joked to him that I'm not sure I trust the real Dan
Barlow, maybe the Araneida author was some identity theif, I just know
that whoever it was using his old PGP key is someone I trust to write
libraries.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
From: Christophe Rhodes
Subject: Re: CLiki and ALU Wiki sites massively spammed
Date:
Message-ID: <sqslrekb6i.fsf@cam.ac.uk>
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Christophe Rhodes <·····@cam.ac.uk> writes:
>
>> No. If my DNS has been hit by spoofing or the host they use is
>> compromised, and I download a package that is signed by someone not in
>> my trust ring (or not signed at all), then the system will have done
>> its job: it will have alerted me to the fact that a package might not
>> be what it seems. It is true that this relies on authors not being
>> terribly stupid with their gpg private keys, and also on some minimal
>> physical connection with the PGP Web of Trust, but it in no way relies
>> on the integrity of any internet host.
>
> Some web of trust connection is a plus, I guess, but it's really
> unnecessary. I got to meet Dan Barlow face-to-face for the first time
> at the last European Lisp Meeting, when he was distributing his new
> PGP key. I joked to him that I'm not sure I trust the real Dan
> Barlow, maybe the Araneida author was some identity theif, I just know
> that whoever it was using his old PGP key is someone I trust to write
> libraries.
:-) Yes, when there's already a well-established history of releases,
signed mails and so on, trusting the physical identity isn't a big
deal, because it is the online persona that you're interacting with.
When someone comes along who doesn't have this online cryptographic
history (and yet releases software that is interesting) is when one
should feel slightly better if there's a web of trust connection.
Christophe
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Some web of trust connection is a plus, I guess, but it's really
> unnecessary. I got to meet Dan Barlow face-to-face for the first time
> at the last European Lisp Meeting, when he was distributing his new
> PGP key. I joked to him that I'm not sure I trust the real Dan
By the way, how does one start creating a web of trust? Are only
face-to-face meetings considered sufficiently safe? What about, say,
phone calls?
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
On 9364 day of my life Paolo Amoroso wrote:
>> Some web of trust connection is a plus, I guess, but it's really
>> unnecessary. I got to meet Dan Barlow face-to-face for the first time
>> at the last European Lisp Meeting, when he was distributing his new
>> PGP key. I joked to him that I'm not sure I trust the real Dan
>
> By the way, how does one start creating a web of trust? Are only
> face-to-face meetings considered sufficiently safe? What about, say,
> phone calls?
If you know a someone personally very well, exchanging key
fingerprints with phone call is rather safe. But with stranger it is
useless:
Mallory: Hi, Paolo! I am Amanda. My key is 0xDEADBEEF.
Paolo: Well... OK.
Actually there are many ways of building WOT. The only problem is not
to mix WOTs build with different principles. Common WOT is based on
strict rules (face-to-face). But there are may be other WOTs based on
relaxed rules: you sign other key if you check only Internet identity
(with signed messages on USENET/maillist, signed software etc.). But
you should remember: 1. Such WOT is easier to attack. 2. You should
use different keys for keysigning in different WOTs.
Anyway, there are also local (non-public) signatures.
--
Ivan Boldyrev
Violets are red
Roses are blue
It's amazing what DNA splicing can do.
Christophe Rhodes wrote:
> "Nathan Baum" <···········@btinternet.com> writes:
>
> > Christophe Rhodes wrote:
> >> Right, which is why asdf-install does not trust the wiki. Instead, it
> >> asks you to trust library authors.
> >
> > It asks you to trust _Wiki authors_, who may not be the library
> > authors.
>
> No, it doesn't.
It does, for the reason you accept: signatureless packages can be
trivially spoofed. It also requires you trust Wiki authors not to make
packages unavailable, something which could be just as dangerous as
making a fake package if your current version has known exploits.
> >> With a wiki-like scheme, you have to trust
> >> * the individual library authors
> >> and no-one else.
> >
> > Assuming that the host they're using is safe from compromise, that your
> > DNS hasn't been hit by spoofing, and any of a number of other
> > scenarios.
>
> No. If my DNS has been hit by spoofing or the host they use is
> compromised, and I download a package that is signed by someone not in
> my trust ring (or not signed at all), then the system will have done
> its job: it will have alerted me to the fact that a package might not
> be what it seems. It is true that this relies on authors not being
> terribly stupid with their gpg private keys, and also on some minimal
> physical connection with the PGP Web of Trust, but it in no way relies
> on the integrity of any internet host.
You're right about the DNS spoofing, but not necessarily right about
the compromised host. Because of the way the Wiki system works, content
is not (necessarily) hosted by a third party. If I host a package on my
personal host and make it available via CLiki, and then my host is
compromised then it is possible that the attacker could sign a
corrupted package with my key.
> Christophe
From: Christophe Rhodes
Subject: Re: CLiki and ALU Wiki sites massively spammed
Date:
Message-ID: <sq8xt6k2ec.fsf@cam.ac.uk>
"Nathan Baum" <···········@btinternet.com> writes:
> Christophe Rhodes wrote:
>> "Nathan Baum" <···········@btinternet.com> writes:
>>
>> > It asks you to trust _Wiki authors_, who may not be the library
>> > authors.
>>
>> No, it doesn't.
>
> It does, for the reason you accept: signatureless packages can be
> trivially spoofed. It also requires you trust Wiki authors not to make
> packages unavailable, something which could be just as dangerous as
> making a fake package if your current version has known exploits.
It puts up a great big warning if you attempt to install a
signatureless package, just as it puts up a great big warning if you
attempt to install one with an unknown key's signature. That it
allows you to shoot yourself in the foot by continuing is not really
an expression of trust in Wiki authors, though I will happily concede
that asdf-install does not make it impossible for you to install
unsigned packages. (It also doesn't make it impossible for you to
download and compile them manually.) Maintenance of a Wiki is of
course a necessity, but at least a Wiki is not vulnerable to the
single auditor going on holiday or otherwise being unavailable at a
the time when hypothetical exploits in CL packages have been
discovered.
>> No. If my DNS has been hit by spoofing or the host they use is
>> compromised, and I download a package that is signed by someone not in
>> my trust ring (or not signed at all), then the system will have done
>> its job: it will have alerted me to the fact that a package might not
>> be what it seems. It is true that this relies on authors not being
>> terribly stupid with their gpg private keys, and also on some minimal
>> physical connection with the PGP Web of Trust, but it in no way relies
>> on the integrity of any internet host.
>
> You're right about the DNS spoofing, but not necessarily right about
> the compromised host. Because of the way the Wiki system works, content
> is not (necessarily) hosted by a third party. If I host a package on my
> personal host and make it available via CLiki, and then my host is
> compromised then it is possible that the attacker could sign a
> corrupted package with my key.
It's possible, yes, if your key is compromised by being used on a host
which has itself been compromised (and the attacker has installed a
keylogger or trojanned gpg binary). However, in most reasonable
situation, this is not one host compromise but two: the
internet-facing public host, and the host used for key signing. This
is by no means impossible (and of course host compromises are
correlated in time and network space) but it isn't a single point of
failure either, and I hope you're not attempting to use this moderate
weakness as an argument for the worse weakness of a
centrally-organized model.
You seem to be arguing that the current system is flawed, and
therefore Something Must Be Done. I'm quite happy (unlike some people
in this thread) to acknowledge that there is no absolute security, or
even security by consensus. By no means is the distributed trust of
gpg a panacea, but I believe that it's better than the various "fixes"
to the current situation that have been proposed here.
Christophe
From: Edi Weitz
Subject: Re: CLiki and ALU Wiki sites massively spammed
Date:
Message-ID: <uk6crm0wf.fsf@agharta.de>
On Mon, 23 Jan 2006 14:43:04 +0000, Christophe Rhodes <·····@cam.ac.uk> wrote:
> Right, which is why asdf-install does not trust the wiki. Instead,
> it asks you to trust library authors.
>
> With a centralised scheme, you would have to trust
> * the maintainer of the links, and
> * the individual library authors
> unless of course you think that the maintainer of the links should
> be doing source code auditing, in which case you have to trust the
> maintainer of the links an awful lot, and also that the host they're
> using is safe from compromise, and that your DNS hasn't been hit by
> spoofing, and any of a number of other scenarios.
>
> With a wiki-like scheme, you have to trust
> * the individual library authors
> and no-one else.
Right, that's the theory. In practice, a lot of authors who make
their packages ASDF-INSTALLable don't even provide a PGP key. And if
they do, it's hard to trust someone you've never seen. Exchanging
keys face to face (yep, everyone please come to the next ECLM[1]) and
signing them helps a bit, but if you desperately want to use the new
CL-FNORK library from this guy in Alaska, you probably don't want to
to wait until a pal of yours happens to meet him at some conference in
Mexico City.
I don't know if a centralized server where authors have accounts is a
better solution but it seems to be good enough for the Perl guys. I
don't use ASDF-INSTALL myself but it is my impression that its goal
was/is to create an infrastructure similar to CPAN. This would
certainly be a good thing for newbies and I think it wouldn't hurt to
check how they're doing it over there.
I hear some people are working on something like "ASDF-INSTALL II" -
maybe one of the new features should be a user-configurable way to get
at the tarball URLs.
Just my useless .02 Euros.
Cheers,
Edi.
[1] <http://weitz.de/eclm2006/>
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Christophe Rhodes
Subject: Re: CLiki and ALU Wiki sites massively spammed
Date:
Message-ID: <sq1wyzx8g7.fsf@cam.ac.uk>
Edi Weitz <········@agharta.de> writes:
> On Mon, 23 Jan 2006 14:43:04 +0000, Christophe Rhodes <·····@cam.ac.uk> wrote:
>
>> Right, which is why asdf-install does not trust the wiki. Instead,
>> it asks you to trust library authors.
>>
>> With a centralised scheme, you would have to trust
>> * the maintainer of the links, and
>> * the individual library authors
>> unless of course you think that the maintainer of the links should
>> be doing source code auditing, in which case you have to trust the
>> maintainer of the links an awful lot, and also that the host they're
>> using is safe from compromise, and that your DNS hasn't been hit by
>> spoofing, and any of a number of other scenarios.
>>
>> With a wiki-like scheme, you have to trust
>> * the individual library authors
>> and no-one else.
>
> Right, that's the theory. In practice, a lot of authors who make
> their packages ASDF-INSTALLable don't even provide a PGP key.
This is a problem. Name and shame, because there's no excuse for
this!
> And if they do, it's hard to trust someone you've never seen.
This, I think, is slightly less true. After all, you aren't actually
declaring a trust in everything the owner of a key does; you're
declaring a trust that the owner of a key won't release malicious or
destructive software. I think there are multiple ways of gaining that
trust, not all of which involve a face-to-face meeting: for instance,
valuable participation in various relevant fora with a ~/.signature
pointing to a web page with a key fingerprint is probably enough to
establish trust for the purpose of compiling code.
> Exchanging keys face to face (yep, everyone please come to the next
> ECLM[1]) and signing them helps a bit, but if you desperately want
> to use the new CL-FNORK library from this guy in Alaska, you
> probably don't want to to wait until a pal of yours happens to meet
> him at some conference in Mexico City.
True. If you're desperate, maybe you should read the code, which
you'll almost certainly have to do anyway to use it, given the state
of documentation in this world... :-)
> I don't know if a centralized server where authors have accounts is a
> better solution but it seems to be good enough for the Perl guys.
I don't know how a centralized server solves the problem of having to
trust that the code you've downloaded isn't malicious or destructive;
I don't use CPAN, but I'm not sure that this issue is addressed (I
couldn't find any discussion of it in either the CPAN or the PAUSE
FAQs.)
> I hear some people are working on something like "ASDF-INSTALL II" -
> maybe one of the new features should be a user-configurable way to get
> at the tarball URLs.
There is plenty of space for exploration of useful features in this
space, I agree.
Christophe
Christophe Rhodes <·····@cam.ac.uk> writes:
> Bill Atkins <············@rpi.edu> writes:
>
>> Christophe Rhodes <·····@cam.ac.uk> writes:
>>
>>> This is a good reason not to blindly disable or ignore the gpg
>>> checking for software downloaded using asdf-install.
>>
>> Still, it seems like pulling the addresses from a wiki is just asking
>> for trouble. What would be the problem (aside from finding someone to
>> do it) with running a dedicated server (a la CPAN) from which
>> ASDF-INSTALL could pull links? There is the issue of being able to
>> trust the people who decide what links go in, but that seems like an
>> easier thing to do than to trust a wiki.
>
> Right, which is why asdf-install does not trust the wiki. Instead, it
> asks you to trust library authors.
>
> With a centralised scheme, you would have to trust
> * the maintainer of the links, and
> * the individual library authors
Indeed. Even repected mainteners like gnu.org had security problems
with their servers...
> unless of course you think that the maintainer of the links should be
> doing source code auditing, in which case you have to trust the
> maintainer of the links an awful lot, and also that the host they're
> using is safe from compromise, and that your DNS hasn't been hit by
> spoofing, and any of a number of other scenarios.
>
> With a wiki-like scheme, you have to trust
> * the individual library authors
> and no-one else.
>
> I fail to see any security advantage at all from a centralised scheme.
Gardeners! We'd need a more structured way to publish the libraries.
The converse of asdf-install: asdf-publish, which would take the
system, package it, sign it, fetch a list of current mirror servers,
and send it to them. Then asdf-install could download the packages
not only from one server referenced from a centralized wiki, but from
a range of mirrors. Well, "standard" distribution stuff... If only I
had more time. Anybody has a time machine?
--
__Pascal Bourguignon__ http://www.informatimago.com/
HANDLE WITH EXTREME CARE: This product contains minute electrically
charged particles moving at velocities in excess of five hundred
million miles per hour.
Pascal Bourguignon wrote:
> Gardeners! We'd need a more structured way to publish the libraries.
> The converse of asdf-install: asdf-publish, which would take the
> system, package it, sign it, fetch a list of current mirror servers,
> and send it to them. Then asdf-install could download the packages
> not only from one server referenced from a centralized wiki, but from
> a range of mirrors. Well, "standard" distribution stuff... If only I
> had more time. Anybody has a time machine?
I've created a Gardeners project, here
http://wiki.alu.org/Securing_ASDF, that will aim to be a band-aid fix.
Hopefully someone will run with the idea & get something in place real
soon now.
Brad
bradb <··············@gmail.com> wrote:
> I've created a Gardeners project, here
> http://wiki.alu.org/Securing_ASDF, that will aim to be a band-aid fix.
> Hopefully someone will run with the idea & get something in place real
> soon now.
I'm not sure why this is suddenly an "OH MY GOD! THE SKY IS FALLING!
We have to do something QUICK!" issue, but this seems like a
worst-of-all-worlds proposal.
* It doesn't actually improve security
* Instead it gives a false sense of security ("no need to check the
signature/think of trust issues, I got it from the secure server")
* It requires drudgework for little benefit. Once the initial burst
of gardener enthusiasm is gone, who is going to be interested in
doing this sort of work long-term?
* Once the people who become the central body start dropping
off/going on holidays/delay propagating the changes for whatever
reason, users are going to hold off installing perfectly good
packages. "It wasn't on the secure server, must be dodgy".
Which isn't to say that the current asdf-install infrastructure
couldn't be improved. Maybe the effort would be better spent on coming
up with real solutions to real shortcomings, instead of band-aids to
non-problems?
--
Juho Snellman
That is also the feedback that I am getting on the Gardeners list.
Perhaps someone who is interested in fixing ASDF-INSTALL will modify
the project to be actually secure, and start working on it. I'm
personally not interested in fixing it right now, I just had a few
minutes to write up the beginnings of a project page.
Cheers
Brad
From: Christophe Rhodes
Subject: Re: CLiki and ALU Wiki sites massively spammed
Date:
Message-ID: <sqoe22kazi.fsf@cam.ac.uk>
"bradb" <··············@gmail.com> writes:
> That is also the feedback that I am getting on the Gardeners list.
> Perhaps someone who is interested in fixing ASDF-INSTALL will modify
> the project to be actually secure, and start working on it. I'm
> personally not interested in fixing it right now, I just had a few
> minutes to write up the beginnings of a project page.
"actually secure" from whose perspective?
When you have a few more minutes to spend on this, perhaps you could
give that question a little thought. Of course, if you're not
interested, then you needn't bother, but you might learn something.
Christophe
"Actually secure", by consensus. At the moment, ASDF-INSTALL is IMHO
secure from the theoretical standpoint only. What I mean is that in
theory packages are signed by the author, and that signature is
validated and accepted by the user of ASDF-INSTALL. Trusting an
author's signature is probably a pretty valid thing to do, even if they
are outside your current trust ring - after all they wrote the code &
you think that you want to use it. However, in my ASDF-INSTALL
experiance, every single package warned me about not matching/finding
(I don't remember the exact message) the GPG signature, and would I
like to blindly ignore it. I ignored it every time, as I suspect most
non-paranoid newbies will do. This is bad social practice and it is
what makes, IMHO, ASDF-INSTALL insecure. The big improvement that
should be made is that key checks should be made automatically, and
only barf an error up when there really is a problem & the chance of
attack is high.
Cheers
Brad
bradb <··············@gmail.com> writes:
> The big improvement that should be made is that key checks should be
> made automatically, and only barf an error up when there really is a
> problem & the chance of attack is high.
The key checks are done automatically. The error here is in not having
acquired the authors' public keys before attempting installation of a
signed packaged.
--
Steven E. Harris
"Steven E. Harris" <···@panix.com> writes:
> bradb <··············@gmail.com> writes:
>
>> The big improvement that should be made is that key checks should be
>> made automatically, and only barf an error up when there really is a
>> problem & the chance of attack is high.
>
> The key checks are done automatically. The error here is in not having
> acquired the authors' public keys before attempting installation of a
> signed packaged.
Ok, so the improvement we need on asdf-install is:
- that it aquires automatically the needed keys (only report the thrust on it).
- that it refuses absolutely to install the package without the right keys.
--
__Pascal Bourguignon__ http://www.informatimago.com/
PLEASE NOTE: Some quantum physics theories suggest that when the
consumer is not directly observing this product, it may cease to
exist or will exist only in a vague and undetermined state.
Pascal Bourguignon <····@mouse-potato.com> writes:
> "Steven E. Harris" <···@panix.com> writes:
>
> > bradb <··············@gmail.com> writes:
> >
> >> The big improvement that should be made is that key checks should be
> >> made automatically, and only barf an error up when there really is a
> >> problem & the chance of attack is high.
> >
> > The key checks are done automatically. The error here is in not having
> > acquired the authors' public keys before attempting installation of a
> > signed packaged.
>
> Ok, so the improvement we need on asdf-install is:
> - that it aquires automatically the needed keys (only report the thrust on it).
> - that it refuses absolutely to install the package without the right keys.
>
I think we should be able to learn a lot in this debate from the way
various Linux distributions handle this. For example, Debian's
apt-get. Most people don't use the main Debian controlled archive, but
instead use a mirror. In reality, we don't necessarily know the level
of security provided by a mirror site either. Its really down to the
user to ensure they are using a reputable site.
Debian and Red Hat use a combination of signed keys and md5
checksums. I think that in reality this is sufficient. We shouldn't be
aiming for absolute security because I don't think such a beast really
exists and we should put som eof the responsability on the end user.
I think asdf install should allow the user to control what
repositories are used. There are genuine issues regarding wiki sites
being used as a repository, but if the end user is prepared to accept
that risk, then so be it. I would not agree with a system which did
not give the user the choice - warn them when keys or checksums don't
match, but give them the choice. Security is not an absolute - for
example, I have very strong security on my system at work because I
have considerable sensitive data. I have very little security on my
system at home because my sensitive/important data is on a different
system which is tightly locked down. For me, the convenience of
accessing my main home system, both locally and remotely, is more
important than having it tightly locked down. I know the system is not
super secure and treat it accordingly - if someone hacks it, well, so
be it - its inconvenient, but it will give me the motivation to do a
fresh install and there isn't anything on there I'm that worried
about. I also use the system for testing software, much of which I
obtain from the Internet and don't really have any way to evaluate its
security etc other than installing it and looking at the sources etc.
I also beleive that if we are successful in establishing a repository
similar to Perl's CPAN, the wiki issue will likely become mute as we
would expect mirrors to be established etc. All we really need is a
fairly straight-forward system that uses key signing and checksums to
provide a reasonable level of confidence - bottom line is that if your
really concerned about security, you really should be inspecting the
sources anyway. Its not unreasonable to expect that at sometime,
somebody will attempt to embed some sort of back-door in their
software, even if its just to see how many people just download it and
install it. Such a bit of software, would have the correct keys and
checksums, but would still be a threat. With open source, it should be
"user beware" instead of "buyer beware".
Tim
--
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you
really need to send mail, you should be able to work it out!
From: Christophe Rhodes
Subject: Re: CLiki and ALU Wiki sites massively spammed
Date:
Message-ID: <sqhd7uk74u.fsf@cam.ac.uk>
"bradb" <··············@gmail.com> writes:
> "Actually secure", by consensus.
Does this mean people who have a clue get a veto, or is a majority of
those willing to design a wiki page in a few spare minutes all that is
required? Whose "consensus"?
> I ignored it every time, as I suspect most non-paranoid newbies will
> do. This is bad social practice and it is what makes, IMHO,
> ASDF-INSTALL insecure.
Most people these days are aware of the notion that they shouldn't
blindly run code straight from the Internet, particularly when given a
warning, and I would expect programmers to be more than averagely
sensitive to this. Of course, quite possibly your choice to ignore
security warnings (and not to bother to take the time to understand
where they're coming from) is quite possibly the rational choice in
your circumstances, but to project your situation to the majority of
intelligent newcomers belittles them.
Christophe
Perhaps I do attribute too little to new-comers to asdf-install
security, perhaps I am the only person who has ignored the security
warnings. Or maybe people want things to Just Work without having to
jump through flaming hoops.
I guess if someone wants to make asdf-install safer and easier they
will, otherwise we will continue as we are. People who are security
aware will survive any attacks, those who aren't will probably get
hammered at some stage.
Getting the author keys is too hard (or at least non-obvious), or if it
is easy then how to do it should be on the Cliki page. You can setup
to fetch keys, but the Cliki page warns that you have basically just
thrown out the security. So what is a newbie to ASDF-INSTALL to do?
Personally, I just stopped using it.
Brad
On Mon, 23 Jan 2006 13:03:16 -0800, bradb wrote:
> Perhaps I do attribute too little to new-comers to asdf-install
> security, perhaps I am the only person who has ignored the security
> warnings.
If I recall correctly, Marco ignores a GPG-check warning in his brilliant
SLIME movie. I remember seeing that and thinking "oh good, I guess I'm
not the only one then" ;-)
To be fair, I think Marco does say something along the lines of "don't try
this at home".
Cheers,
Bill.
bradb <··············@gmail.com> wrote:
> Getting the author keys is too hard (or at least non-obvious), or if it
> is easy then how to do it should be on the Cliki page. You can setup
> to fetch keys, but the Cliki page warns that you have basically just
> thrown out the security. So what is a newbie to ASDF-INSTALL to do?
> Personally, I just stopped using it.
And how do you decide that the code that manually download is
valid/trustworthy/secure/whatever? You can get the same level of
"security" by applying the same process to ASDF-INSTALL. For some
reason I doubt that it's a very rigorous one.
Since ASDF-INSTALL automatically checks signatures (which few people
would normally do) and actively encourages the users to actually think
of trust issues (which few people normally do, as is obvious from this
discussion), I'd suggest that it's in practice a more trustworthy
method of installing software than just downloading it yourself.
Despite the links being on a globally editable Wiki.
--
Juho Snellman
Hi.
On 2006-01-23, bradb <··············@gmail.com> wrote:
> Getting the author keys is too hard (or at least non-obvious), or if it
> is easy then how to do it should be on the Cliki page. You can setup
> to fetch keys, but the Cliki page warns that you have basically just
> thrown out the security. So what is a newbie to ASDF-INSTALL to do?
> Personally, I just stopped using it.
It's not that you've totally thrown out security, but automatic key
fetching does remove some of the immediate pressure to actually do
web-of-trust maintenance on your keyring (actually getting things
signed, exchanging signatures, etc), and some would argue that there is
an additional trust value in obtaining an author's key from some
non-wiki source (something that looks like their homepage).
You still get prompted if the key isn't one on your trusted author list,
so it's possible that some lisp package maintainer you trust could do
something evil with another package (such is the nature of trust), but
some random rogue can't just replace cl-ppcre with something evil. It's
true that the process requires a user to think, but that doesn't make it
inferior or less secure than processes which discourage users from
thinking about security.
It would be nice if developers made sure their public keys were on the
public key servers, though. I just tried to check cl-yacc and diff, and
was surprised to find that neither's authors keys could be found on the
default wwwkeys server I was using.
I don't see any problem with the system as it stands, except that it
could do with some cleanup (make sure all packages are signed and the
keys are available). I would be sad to see it go to the centralized
server model, as I don't see that it really provides any security value
other than warm fuzzy feelings.
Cheers.
--
Julian Squires
Julian Squires <······@cipht.net> writes:
> Hi.
>
> On 2006-01-23, bradb <··············@gmail.com> wrote:
>> Getting the author keys is too hard (or at least non-obvious), or if it
>> is easy then how to do it should be on the Cliki page. You can setup
>> to fetch keys, but the Cliki page warns that you have basically just
>> thrown out the security. So what is a newbie to ASDF-INSTALL to do?
>> Personally, I just stopped using it.
>
> It's not that you've totally thrown out security, but automatic key
> fetching does remove some of the immediate pressure to actually do
> web-of-trust maintenance on your keyring (actually getting things
> signed, exchanging signatures, etc), and some would argue that there is
> an additional trust value in obtaining an author's key from some
> non-wiki source (something that looks like their homepage).
Of course, you dont' get keys from the wiki! Silly!
You get the keys from the pgp keyservers.
> You still get prompted if the key isn't one on your trusted author list,
> so it's possible that some lisp package maintainer you trust could do
> something evil with another package (such is the nature of trust), but
> some random rogue can't just replace cl-ppcre with something evil. It's
> true that the process requires a user to think, but that doesn't make it
> inferior or less secure than processes which discourage users from
> thinking about security.
Thrust is another matter. When you fetch keys, they don't become
automatically thrusted.
> It would be nice if developers made sure their public keys were on the
> public key servers, though.
This could be done automatically by a asdf-publish tool...
> I just tried to check cl-yacc and diff, and
> was surprised to find that neither's authors keys could be found on the
> default wwwkeys server I was using.
Indeed this is a problem.
> I don't see any problem with the system as it stands, except that it
> could do with some cleanup (make sure all packages are signed and the
> keys are available). I would be sad to see it go to the centralized
> server model, as I don't see that it really provides any security value
> other than warm fuzzy feelings.
>
> Cheers.
>
> --
> Julian Squires
--
__Pascal Bourguignon__ http://www.informatimago.com/
Kitty like plastic.
Confuses for litter box.
Don't leave tarp around.
Julian Squires <······@cipht.net> writes:
> It would be nice if developers made sure their public keys were on the
> public key servers, though. I just tried to check cl-yacc and diff, and
> was surprised to find that neither's authors keys could be found on the
> default wwwkeys server I was using.
Huh?
$ curl http://www.pps.jussieu.fr/~jch/software/files/cl-yacc-0.2.tar.gz.asc | gpg --list-pack
:signature packet: algo 17, keyid 3B27FA8777FF5F3B
version 3, created 1134190210, md5len 5, sigclass 00
digest algo 2, begin of digest 73 83
data: [159 bits]
data: [159 bits]
$ gpg --recv 3B27FA8777FF5F3B
gpg: requesting key 77FF5F3B from hkp server subkeys.pgp.net
gpg: key 77FF5F3B: "Juliusz Chroboczek <···@pps.jussieu.fr>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1
$
Do keyservers no longer synchronise automatically?
Juilusz
On 2006-01-24, Juliusz Chroboczek <···@pps.jussieu.fr> wrote:
> Julian Squires <······@cipht.net> writes:
>
>> It would be nice if developers made sure their public keys were on the
>> public key servers, though. I just tried to check cl-yacc and diff, and
>> was surprised to find that neither's authors keys could be found on the
>> default wwwkeys server I was using.
>
> Huh?
Ah, my mistake (with cl-yacc); looking back at my history I see that
this is what happened:
"gpg: Signature made Sat 10 Dec 2005 01:20:10 AM NST using DSA key ID 77FF5F3B"
"gpg: requesting key 77FF5F3B from hkp server wwwkeys.pgp.net"
"gpg: lock not made: link() failed: Operation not permitted"
"gpg: can't lock `/home/julian/.gnupg/pubring.gpg'"
"gpg: error writing keyring `/home/julian/.gnupg/pubring.gpg': general error"
"gpg: key 77FF5F3B: public key \"[User ID not found]\" imported"
"[GNUPG:] IMPORTED 3B27FA8777FF5F3B [?]"
"[GNUPG:] IMPORT_OK 1 57A6F2FEA85FA2ECA8B57EBE3B27FA8777FF5F3B"
"gpg: error reading `[stream]': general error"
"gpg: Total number processed: 0"
"gpg: imported: 1"
"[GNUPG:] IMPORT_RES 0 0 1 0 0 0 0 0 0 0 0 0 0 0"
"[GNUPG:] ERRSIG 3B27FA8777FF5F3B 17 2 00 1134190210 9"
"[GNUPG:] NO_PUBKEY 3B27FA8777FF5F3B"
"gpg: Can't check signature: public key not found"
Obviously I didn't pay close enough attention to the cause of the
failure. Sorry for the false alarm.
--
Julian Squires
Juho Snellman <······@iki.fi> writes:
> bradb <··············@gmail.com> wrote:
>> I've created a Gardeners project, here
>> http://wiki.alu.org/Securing_ASDF, that will aim to be a band-aid fix.
>> Hopefully someone will run with the idea & get something in place real
>> soon now.
>
> I'm not sure why this is suddenly an "OH MY GOD! THE SKY IS FALLING!
> We have to do something QUICK!" issue, but this seems like a
> worst-of-all-worlds proposal.
>
> * It doesn't actually improve security
> * Instead it gives a false sense of security ("no need to check the
> signature/think of trust issues, I got it from the secure server")
> * It requires drudgework for little benefit. Once the initial burst
> of gardener enthusiasm is gone, who is going to be interested in
> doing this sort of work long-term?
> * Once the people who become the central body start dropping
> off/going on holidays/delay propagating the changes for whatever
> reason, users are going to hold off installing perfectly good
> packages. "It wasn't on the secure server, must be dodgy".
>
> Which isn't to say that the current asdf-install infrastructure
> couldn't be improved. Maybe the effort would be better spent on coming
> up with real solutions to real shortcomings, instead of band-aids to
> non-problems?
FWIW, the brief discussion of this project on the Gardeners' mailing
list has already moved somewhat in the direction of figuring out ways
to enhance the web-of-trust. Folks who care about this may want to
browse the list archives[1] or check out the conversation via Gmane to
see if we're going off in the tall weeds. Or if you care a lot
subscribe[2] to the list and/or add comments to the project page at:
<http://wiki.alu.org/Securing_ASDF>
-Peter
[1] <http://www.lispniks.com/pipermail/gardeners/>
[2] <http://www.lispniks.com/mailman/listinfo/gardeners>
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Peter Seibel <·····@gigamonkeys.com> writes:
> Juho Snellman <······@iki.fi> writes:
>
>> bradb <··············@gmail.com> wrote:
>>> I've created a Gardeners project, here
>>> http://wiki.alu.org/Securing_ASDF, that will aim to be a band-aid fix.
>>> Hopefully someone will run with the idea & get something in place real
>>> soon now.
>>
>> I'm not sure why this is suddenly an "OH MY GOD! THE SKY IS
>> FALLING! We have to do something QUICK!" issue, but this seems like
>> a worst-of-all-worlds proposal.
In addition to my other comment about the direction of this project in
particular, let me point out that just because someone creates a
"Gardeners' project", it doesn't necessarily mean that folks are going
to be working on it. At the moment there are four categories of
projects:
- Unchampioned projects -- things that someone thought might be a
good idea but which no one has picked up the ball on.
- Championed projects -- a project that has at least one person
who's interested in moving forward.
- Proposed projects -- projects that have a champion *and* which the
champion feels is well-defined enough for others to be able to
decide whether they might like to help out.
- Official projects -- proposed projects that have been "blessed" by
The Green Thumbs, a group of Gardeners muckityy-mucks who use an
Apache-style voting scheme to decide whether a project is in fact
well-defined enough for it to a) do some good b) allow other folks
to contribute.
When Brad said he had "created a project" that just meant that he had
created a project page and added it to the list of unchampioned
projects. Whether it goes any further will depend on whether anyone
decides its worth championing and doing the work to actually define
what the project is going to try and do.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
> I've created a Gardeners project, here
> http://wiki.alu.org/Securing_ASDF, that will aim to be a band-aid fix.
> Hopefully someone will run with the idea & get something in place real
> soon now.
I think the real issue is that A-I cannot be told to use multiple
sources for fetching signatures.
I think the solution would be to allow A-I to fetch extra signatures
from well-known places, and allow installation of the package if any
of the signatures is valid and has a trusted key. So for example,
when A-I finds that the key used in cl-yacc-0.2.tar.gz.asc is untrusted,
it will fetch
http://www.gardeners.org/signatures/da39a3ee5e6b4b0d3255bfef95601890afd80709.asc
where the hex string is the SHA-1 hash of cl-yacc-0.2.tar.gz. In that
file, it will find a valid signature by "Common Lisp Gardeners
(Software signing only)", which happens to be trusted, and accept the
package.
Note that this scheme:
- doesn't require the web server with extra signatures to be secure
(as long as the keys are secure, of course);
- doesn't require file names or web locations of packages to be
stable;
- doesn't weaken security if you don't choose to trust any extra keys;
- is extensible ad lib if A-I allows multiple extra locations for
signatures.
Juliusz Chroboczek
Christophe Rhodes <·····@cam.ac.uk> wrote:
> Right, which is why asdf-install does not trust the wiki. Instead, it
> asks you to trust library authors.
The key.
But I don't know anyone who uses PGP or GnuPG. When I ask someone
to sign my key I have to explain things and get some laughs
because of the geekiness of all this.
Even at some gathering of real nerds some years ago. Funny thing
the club I left some time ago has started a CA few months later.
Don't know if I would trust them. :-)
So, you can't really trust all the keys. Only the source of them:
http://common-lisp.net/keyring.asc
Stefan Scholl <······@no-spoon.de> writes:
> So, you can't really trust all the keys. Only the source of them:
> http://common-lisp.net/keyring.asc
If I've downloaded that file and imported it into a keyring file, I
can verify that the key B28EDD82 (Common-lisp.net) matches several
fingerprints I find reported through Google searches. I can't find any
page on the common-lisp.net site that discusses the content and use of
the keyring offered. Perhaps at minimum it should make a proclamation
of the master key's fingerprint, or point to a suitable and more
credible listing at, say, Biglumber.
Even after downloading and importing this keyring, perhaps I decide
that I'll grant the master key marginal trust. Is that sufficient
transient trust to satisfy ASDF-INSTALL's requirements for author
keys?
My GnuPG skills with multiple keyring files are under-developed, and
so far none of my trust assertions seem to make any difference when
checking on the author keys.
--
Steven E. Harris
Paolo Amoroso <·······@mclink.it> writes:
> As the CLiki recent changes page shows:
>
> http://www.cliki.net/Recent%20Changes
>
> the site was massively spammed. Something similar happened to the ALU
Dan Barlow has just restored the site from backup--thanks.
> These attacks raise some issues on the safety of links used for
> ASDF-INSTALL.
As has been noted, GPG signature checking is a solution.
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net