Domain: chaosreigns.com
Stories and comments across the archive that link to chaosreigns.com.
Comments · 9
-
Debian GPG-signed Web of Trust
debian has a keysigning process that creates a web of trust.
http://www.chaosreigns.com/code/sig2dot/debian.html
http://www.debian.org/events/keysigning -
Re:Isn't Certificates A Better Way?
Because there are flaws inherent in all central authority anti-spam proposals, such as:
Who is issuing the certificate?
Are they charging for the certificate?
Is the certificate issued to the user or to the provider?
Is the issuer genuinely interested in stemming the tide of spam once it is a revenue source?
Can the certificate be compromised?
If the certificate is compromised, can the user retract the certificates authority easily?
There are already capabilities in most MUAs and MTAs that could easily be implemented to combat spam without breaking the existing infrastructure, but are not being used.
See my my other posts in this discussion for an explanation of what those are and how they can be used.
Checking sender identity would be better done using a Public Key infrastructure rather than a centralized authority (such as VeriSign), because it allows for varying degrees of trust based on who you've had sign your key, permits a user to be relatively anonymous (except to those who he chooses to identify himself to) and actually requires the user to go out and meet someone for their key to be introduced into the "web of trust".
-
Web of trust
You are describing how Debian's web of trust works today. Each key should be (not all are, but most are) signed by at least one other Debian developer. If you take a look at the graphing of the Debian keyring, you will see that it is well-connected. (Note that this graph is old; from august 2000, but the same holds today, and it's probably even better connected).
(look at sig2dot for the tool used to generate the graph.
There is also nothing stopping you from signing keys used for advisories and such, which can then be cross-vendor, and everybody will be happy. -
Web of trust
You are describing how Debian's web of trust works today. Each key should be (not all are, but most are) signed by at least one other Debian developer. If you take a look at the graphing of the Debian keyring, you will see that it is well-connected. (Note that this graph is old; from august 2000, but the same holds today, and it's probably even better connected).
(look at sig2dot for the tool used to generate the graph.
There is also nothing stopping you from signing keys used for advisories and such, which can then be cross-vendor, and everybody will be happy. -
Re:Implementing links policies in an automated way
A friend of mine did just this because he was tired of people consuming his upstream DSL bandwidth. His solution uses mod_rewrite, which comes standard with Apache. (It's a configure/compile-time option in both 1.3 and 2.0, but I'd be highly surprised if a distribution didn't enable it.)
-
sig2dot, the GPG signature relationship grapher...is cooler.
Ever wondered what a plot of a portion of the PGP web of trust would look like? Here it is.
sig2dot generates plotting data from the signatures in your GPG keyring; this data can be rendered by springgraph or graphvis. Many pretty sample plots on the page.
-
Re:Maybe we should lobby the search enginesActually, a friend of mine did just this. Granted, it wasn't to keep people from deep-linking to his site, but it's exactly the same principle and, as you can see, not at all hard to do.
(He's hosting this site behind a slow DSL line and people inlining his images was causing a big bandwidth drain. I don't think he cares about somebody copying images to their own server and using them there.)
-
Re:Maybe we should lobby the search enginesActually, a friend of mine did just this. Granted, it wasn't to keep people from deep-linking to his site, but it's exactly the same principle and, as you can see, not at all hard to do.
(He's hosting this site behind a slow DSL line and people inlining his images was causing a big bandwidth drain. I don't think he cares about somebody copying images to their own server and using them there.)
-
The real problemThe real problem is not lack of bandwidth. There's plenty of it to go around. What saddens me is that the ISC is throwing away most of $80,000 annually because people can't be bothered to patch their kernel, and instead rely on downloading the full 20MB tarball every time a new kernel is released.
The solution to the problem is really quite simple. As Larry McVoy, who maintains the powerful but non-free BitKeeper RCS system and knows a thing or two about patches, has hinted towards kernel.org may be better off not providing a tarball for each release, instead providing some kind of utility that downloads the latest available full kernel, but only if necessary, plus patches. I'd be all for it. In the meantime, there are a number of incremental patching systems for the Linux kernel that automatically download patches, verify their signatures and patch the kernel which may be worth looking into to save time, bandwidth and resources:
- dlkern
- buildkernel
- lkpatch, which has fallen into disrepair
Of course, it goes without saying that everyone should still use their local mirror, particularly as kernel.org will only be accessible to mirrors for the forseeable future.