> IANAL, but only one person in this discussion has mentioned that they
> HAVE consulted one that specializes in data privacy - who confirms that
> specifically, for a US keyserver operator operating a US keyserver, GDPR
> has *absolutely no bearing* even if we *weren't* exempt.
Minor nit: that wa
> Hansen its 2019 not 1990 and you need to evolve your thinking beyond your own
> personal interests!
Yawn. Call me when you've given up on the ad hominem.
> Do you think the GDPR is a bad thing?
I think it's a law enacted by a nation I'm not party to and am not
obligated to obey. That means
Mostly this is a response to Arnold, as for some reason his email never
showed up in my inbox:
> I thought SKS and PGP-keys is about one's ability to hide private
> data (by encryption).
Tools do not have intrinsic purposes. There's the stuff they're
designed for and there's the stuff they actua
> Well, it was just one of many example sites...
Again: I'm going to go with the real advice given to me by real lawyers.
> So as an example, US SKS key server operators do not have to honor
> removal request (in this case shut-down the server) from EU citizens,
> when they receive a letter from
> Please have a read:
Did.
I'm going to believe the privacy lawyer I pay $450 an hour to more than
I'm going to trust a sketchy website that's not even officially
affiliated with the EU. Quoting from it:
"You may be wondering how the European Union will enforce a law in
territory it does not co
> Fair enough. Then you're ignoring the consequences (or rather believe
> that none exist) rather than saying that the GDPR wouldn't apply to US-
> based operators.
Enforcement is the sine qua non of law. GDPR does not apply to purely
US-based operators because there is no way for the EU to eithe
>> There are (or at least were) a large number of US-based keyserver
>> operators who were immune to the GDPR.
>
> I fail to see how this is in accordance with the GDPR.
The EU is free to claim whatever authority it wants, but until it can
enforce that authority it's bluster. If I, as a US citiz
> They are!
No, they're not.
GDPR only applies to business entities that trade with EU citizens in EU
member nations. If a German boards a flight in Colorado to travel to
Texas, they don't get to claim GDPR protections on their tickets. It's
once the flight connects to an EU member state the ai
> https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f
As the guy who wrote that, yeah, I'm pretty sure we here are aware of
it. ;)
Kristian, who is the major figure behind the SKS keyserver network, has
also apparently been targeted. We are keenly aware of the issue. But
thank yo
> It is no use to wait a great consensus.
Without exception, I have never met someone who was reluctant to
volunteer someone else's time. I think this is unfortunate. I'd rather
we were as reluctant to urge other people to commit their time and
effort to a project as we are to commit our own.
> I disagree that we have to do a trade off, mostly for technical
> reasons.
Let's call forbidden information 'kryptonite'. Kryptonite is bad stuff.
We don't want it on moral grounds or legal grounds. We would rather
shut down keyservers than have kryptonite on our systems. We then have
three
To spare us all diving through list archives:
The keyserver network is in a lot of ways like a blockchain. In both
cases they are distributed ledgers where any change to the ledger is
propagated through to everyone with a copy of the ledger. (Blockchain
differs by adding more cryptographic verif
> Is it possible to develop a keyserver thar uses the same interface as
> the current one?
Sort of.
> Meaning that GnuPG-Clients don't need to change
Yes.
> and current keyservers can recon with the new keyservers (since they
> are not all upgraded simultaniously)?
No. Keyserver reconciliatio
> If only it were open-source software and individuals with the extra time
> and talent to work on those design flaws were able to do so. Wouldn't
> that be a great world to live in?
Wouldn't it be great if people were to think before snarking?
There are a handful of people with the background an
> Kristian says in his interview the network was not designed to be resilient?
Kinda-sorta. The basic keyserver architecture was designed in the very
early 1990s, and it's really quite resilient against the sorts of
threats we saw in the 1990s.
But the threat actors and their capabilities have v
> Then let's drop keys that don't contain a valid email address in the key id.
How do you propose to validate the email address?
(Hint: this is a surprisingly hard problem.)
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailm
> I think the time has come where we have to re-evaluate what the
> keyservers are *for*. Once we answer that, we answer what should be
> done about it.
I agree, although I think maybe you're not taking it far enough.
What threats should we be defending against?
The original idea of a keyserver
> In the new era key owners have to proof their identity. Practically
> speaking key servers accept only keys belonging to the strong set.
> (At least in first step.)
Who says the next technology needs to be key servers? That seems like
an assumption worth challenging.
I'm not throwing this out
> Does a user revolt even matter as the SKS pool is dismantled by
> continuous attacks?
"We had to burn the village in order to save it!", I see.
There are three questions:
1. Can SKS be saved?
2. If so, how?
3. If not, what next?
I believe the answers are "no", "N/A", and "I don't know yet.
> IMHO Photo-ID should be dropped entirely, I see no point and its just
> ripe for abuse like this..
Unfortunately, we really can't. They've been part of OpenPGP
certificates for just about twenty years now. They are an expected part
of the certificate. Users already scream bloody murder about
> Sad but not surprised. Thanks for all your time and effort. It has been much
> appreciated.
Yes.
> I am reluctant to declare defeat, but this calls for a tactical retreat and
> regroup.
Yes.
There's a certain dark lesson to be learned here. The keyserver network
was designed in the antic
> how can you assume that it was me who uploaded a key with my name on it?
Nobody is. But if you create a public key, then by definition you're
comfortable with it being shared with the public.
If you don't want your public key shared with the public, don't use
asymmetric crypto.
If you didn't
> Please feel free to find the weaknesses in this suggestion !!!
Fine. Remember: you asked for it.
> Suppose we add a POW data to the PGP key data transaction request
>
> We can use the number of 0 in the 160-bit SHA-1 hash as the level of
> complexity indicator.
In *which* SHA-1 hash?
> The
> The administrators of the SKS servers should be able to choose the level
> of complexity of the proof of work using a parameter in the SKS server
> configuration file.
No, they shouldn't. Think about it. If you're an attacker looking to
bypass this mechanism, what do you do? You find the keys
> Let client solve a simple integer factorization of a random number given
> by server with e.g. 64bit build from two prime numbers.
Please sanity-check your ideas first.
Trial division on a 64-bit number requires trying each prime up to
2**32. There are about 200 million of them. 200 million *
> But they kind of do already, so I don't see the point here.
They don't. Let's say a keyserver operator goes rogue and decides to
drop 0xB44427C7 (my cert) from the keyserver network. Great, ten
minutes later it gets replaced during the next sync. So the keyserver
operator deletes it again. T
>> 1. What criteria should be met before a key is removed?
>
> Owner of private key or owner of UID/email address requests it.
So far, so good.
>> 2. Who decides that the criteria have been met?
>
> The keyserver operator the request is sent to.
Going off the rails.
>> 3. How are malicious re
> I'm not sure whether burn care would be really an issues for (most of)
> us... at least not as long cryptography itself isn't made "illegal".
> Our services are typically not illegal or morally questionable...so
> even if "they" would come after you... well... so what?
The "so what?" is, if "the
> On the server side, the only use case (which is actually a good use
> case), I see, would be that we could basically hide keyservers from
> powerful players, that may e.g. force a larger number of keyserver
> operators to delete, obstruct, etc. certain keys or parts of them,
> which may help them
On 9/29/15 8:05 PM, Carles Tubio Terrón wrote:
> - BEGIN PGP MESSAGE-
(Above line slightly mangled to prevent apps from mis-parsing)
Please only send plaintext, or plaintext with an attached signature, to
this mailing list.
___
Sks-devel mailin
> One thing that does concern me about the current arrangements is how
> manual (and ad-hoc) the peering system is. I can foresee scalability
> problems...
Two thoughts:
1. "Speed it, O Lord! Let Thy Kingdom come!" With 50,000 certificates
in the strong set and only a few million certificates
> Even if we did have a better understanding of the filter code, the
> difficulty with phasing in filters like this (as you've noticed in
> your description) is that either the whole pool opts in, or the
> filter doesn't work. Peers with different filtersets cannot gossip
> with each other, aiui.
> Thoughts?
Right now the principal SKS developers and maintainers are Yaron Minsky,
John Clizbe, Christoph Martin, Fabi Di Nitto, Daniel Kahn Gillmor, and
... I'm blanking on the Fedora SKS maintainer.
This idea really needs buy-in from them. So long as it's an idea
floated by people who neithe
> Your tactic adds much, much more significant legal risk since you
> could be arrested for sexual offenses (very long prison sentence plus
> lifelong branding). Most troll organizations don't cross this line,
> and take more technical approaches to DoS'ing a system.
You're thinking like an acade
> Uploading user attribute packets with bogus self-signatures is
> probably the easiest way to DoS the entire keyserver network.
No. No, it's not.
The easiest way is to add a single child porn image to a UID and upload
it to the keyserver, and watch as worldwide every keyserver operator
either
> This is a DOS because Mallory could effectively increase Alice's
> public key to a size that it would be untenable for Bob to
> download it from the pool.
There are so many other, better ways to DoS the entire keyserver network
that I have real trouble taking this one seriously.
I think Kristia
On 8/3/2014 3:06 AM, Kiss Gabor (Bitman) wrote:
> I'm thinking on structure of graph of key servers for a long time.
> IMHO it is too scale free and not designed knowingly enough.
If you haven't read this paper, start with it.
* Watts, Duncan J.; Strogatz, Steven H. (June 1998). "Collective
dynam
On 6/12/2014 2:41 PM, Travis Megee wrote:
... forgive a silly question, but I have to ask: is that your real name,
or an homage to Gregory MacDonald? :)
( http://en.wikipedia.org/wiki/Travis_McGee for those who have never
read a MacDonald novel. Brilliant writing, just brilliant.)
_
> "You've seemingly overlooked that the message was typed on a cell and
> the autocorrect isn't designed for English. 'This message was sent from
> my Android phone via K-9 Mail.' And because you instantly become
> personal in your first post and aren't engaging with the real issues,
> you're dead
> Du hast scheinbar überlesen dass die Nachricht via Handy getippert wurde
I would suggest doing what I do when I send messages in languages other
than English; turn off autocorrect.
As it happens, I have a copy of Brecht's _Leben des Galilei_ on my
endtable right now. Not all Americans are depe
> Agree. Ppl get personal swearing against me but dont had the kindness
> to read the post and try to understand it.
I have read all the posts in this thread and done my best to understand
them. Some things I can't decipher, like
> Hust bame it.
... which is, IMO, a case study in why standard E
On 9/14/2013 3:08 PM, Daniel Kahn Gillmor wrote:
> Let me also be clearer about why i find this bug serious...
I am still not seeing why this bug is serious. It still seems to be a
case of mountains and molehills.
> I have told numerous people that the keyserver network will not
> propagate lo
On 9/13/2013 8:22 PM, Christoph Anton Mitterer wrote:
> And I guess the intention of the RFC is rather clear (with or without
> MUSTs)... implementations should not export such signatures... and SKS
> counts IMO as an "implementation".
In what bizarro universe is SKS an implementation of RFC4880?
On 9/13/2013 7:51 PM, John Clizbe wrote:
> I agree with Werner and Dave Shaw that you are wrong. If you are so
> convinced you are correct, post, with _ALL_ the particulars not just
> those that support your stance, to the IETF-OpenPGP list and get
> their opinion.
Although I agree with DKG that t
On 9/13/2013 6:09 PM, Daniel Kahn Gillmor wrote:
> The intent is pretty clear, despite it not rising to the level of an RFC
> 2119 MUST. Did anyone on this list expect the keyserver network to
> propagate non-exportable certifications?
I did, and I think I'm speaking as a reasonable, rational hum
On 9/13/2013 5:48 PM, Daniel Kahn Gillmor wrote:
> RFC 4880 is explicit:
>
> Some implementations do not represent the interest of a single user
> (for example, a key server). Such implementations always trim local
> certifications from any key they handle.
I don't see a MUST in there. The la
keyservers.org will be down for approximately 8 hours on Tuesday for a
server relocation. As with all server relocations it's possible that
things will spring up that keep it offline for a longer period, but at
present I think 8 hours is about right.
__
Hurricane Sandy is currently projected to make landfall almost on my
front doorstep. For this reason, keyservers.org may go offline anytime
in the near future. If it goes offline, expect it to be gone for a few
days or more.
Hopefully, though, all will be well and this will turn out to be a
temp
On 8/10/2012 11:31 AM, Kristian Fiskerstrand wrote:
> Would it be possible for you to share some information* about the system
> so that I can try to replicate it? (OS, SKS version, etc...).
This is an Ubuntu 12.04 AMD64 system running the latest SKS available
from the normal Ubuntu repository. T
On 8/10/2012 12:45 AM, Robert J. Hansen wrote:
> There is no fix yet, nor do we know exactly what's causing this bug to
> manifest. For now, if your PTree/ subdir gets borked the best way to
> proceed is to rebuild the entire PTree/ subdir:
For what it's worth, I am unabl
John Clizbe and I have both had a problem recently with sks recon
crashing in a way that completely borks the PTree/ subdirectory. If
your sks recon process dies and, upon restarting it, you see this in the
log:
2012-08-10 00:38:56 Raising Sys.Break -- PTree may be corrupted:
Failure("remove_fro
keyservers.org had another brief (couple of hours) outage today due to
another thunderstorm in the DC area. Power and internet has since been
restored, but thousands of people in the DC area aren't yet as lucky.
Other keyservers in the DC Metro Area may be down as well.
Apparently, the local powe
On 7/1/2012 5:26 AM, Kiss Gabor (Bitman) wrote:
> No matter which key server a key I get from.
> No matter who operates a key server.
> The only important thing if a key is signed by trustworthy peoples or not.
In your security model, sure. But please don't go about telling the
world what their m
On 7/1/2012 3:26 AM, Kiss Gabor (Bitman) wrote:
> I respect your opinion but I don't agree. Sorry.
What precisely do you disagree with?
> _All_ key servers of the pool are absolutely untrustable by definition.
Not true. For instance, I trust John Clizbe. If I receive a
certificate from him, I'
On 7/1/2012 2:49 AM, Gabor Kiss wrote:
> Why don't put a CNAME record of keyservers.org pointing to a working
> server? Most of your users won't notice the difference. :)
Because that's fundamentally dishonest.
Some people use keyservers.org indirectly through
pool.sks-keyservers.net. These peop
On 6/30/2012 9:31 PM, Brian D Heaton wrote:
> Glad you and yours are all in one piece. With no power to over a
> million folks, the next few days may get a bit "interesting."
Thanks, Brian.
Yeah, as of right now 1.3 million people are without power during one of
the worst heat streaks DC has eve
On 6/30/2012 4:31 PM, Javier Henderson wrote:
> Weird.
Not particularly: Ashburn is about 30mi/55km due west of my location.
The storm hit the greater DC Metro Area badly, but 55km due west is well
out of the Beltway.
> keyserver.kjsl.org is at Equinix in Ashburn and remained online. This
> datac
Due to a catastrophic set of thunderstorms that have hammered public
utilities in the DC area, keyservers.org is experiencing prolonged
downtime. I don't expect it to be operational for the next couple of
days, and the downtime may extend more than a week. My apologies to
those who are inconvenie
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 06/14/2012 07:09 PM, Phil Pennock wrote:
> As you move away from lists dedicated to highly technical
> concepts, those assumptions break down and it becomes more
> challenging to encourage folks to do some homework first before
> posting so that e
On 06/04/2012 09:56 PM, David Benfell wrote:
> This isn't seeming consistent to me. How do you reconcile...
Quite easily, actually:
>> I've only ever said that the keyservers have always been guided by
>> a "no loss of information, ever" policy.
My position is: "Keyservers have always been guide
On 6/4/12 4:27 PM, Jeffrey Johnson wrote:
> But there are also reasons to add better policies like "Do Not
> Modify" or "I live in the EU and privacy laws permit me to insist
> that my pubkey be removed." to manage server-to-server distribution.
The problem here is that the keyserver network would
On 6/4/12 4:15 PM, Jeffrey Johnson wrote:
> Insisting that SKS key servers *never* undertake some reasonable
> policies for sound engineering purposes isn't subject to the number
> of adamant objectors, but rather to sensible discussion.
There's a difference between saying "these signatures should
On 6/4/12 5:55 AM, Gabor Kiss wrote:
>>> Actually it is not true that SKS does not modify certs.
>>
>> AFAIK, no one in this discussion ever claimed it does.
>
> I did not say that someone stated this. :-)
Then why did you say "It is not true that SKS does not modify certs"?
You're arguing against
On 06/04/2012 03:28 AM, Gabor Kiss wrote:
> Actually it is not true that SKS does not modify certs.
AFAIK, no one in this discussion ever claimed it does. It was claimed
that SKS never deletes information, which rather moots the rest of your
email. :)
___
John's weather troubles are apparently contagious. keyservers.org was
down for a few hours due to thunderstorm and tornado activity in the
Maryland area. Service is now restored.
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/
On 5/31/12 11:58 AM, John Clizbe wrote:
> Other than the name being somewhat offensive in some English speaking
> countries?
I'm going to chime in here on the side of the "git isn't necessary" crowd.
Git is a fine RCS for large distributed projects. For the Linux kernel
it's almost ideal. But
On 05/31/2012 09:33 AM, Robert J. Hansen wrote:
> Now for where things get wacky: running the exact same command, but with
> -n 20 instead of -n 10, causes a segfault in a different part of the code:
-n 5 crashes in yet a different place, although it manages to actually
get through a cou
On 05/31/2012 09:30 AM, Kiss Gabor (Bitman) wrote:
> What if you have no choice?
Let me repeat: if you're trusting the wrong people then you're
goatscrewed and there is no technology that can help you.
There is no Option B.
___
Sks-devel mailing list
S
keyservers.org is a Fedora 15/x64 system running on hardware that's
coming to the end of its expected useful life. isaiah.keyservers.org is
a Fedora 17/x64 system running on much newer and beefier hardware. The
old system runs SKS 1.1.1; the new runs SKS 1.1.3. Both come from the
Fedora repos.
On 05/31/2012 01:41 AM, Gabor Kiss wrote:
> You have trust a long and thin chain of signatures between you
> and your abroad comrade. What if a government agent edged in the chain?
1. Then you're goatscrewed, because you're trusting the wrong people,
and there is *no* technology that can help
On 05/31/2012 12:57 AM, Gabor Kiss wrote:
> There is no guarantee that one can trust all of current key servers.
This is why users are encouraged to use a keyserver they *do* trust.
This is why keyserver operators are encouraged *not* to peer with others
they don't trust. Some operators on this
On 5/27/12 7:10 AM, Robert J. Hansen wrote:
> *These feature requests have clear, obvious downsides.* (Not the least
> of which is they won't work particularly well.)
So, the first question is -- what would be necessary for a solution to
work well?
The brute force and overkill appro
At present, there are no credible reports of the keyserver network being
used to distribute illegal data. I'd like to repeat that: at present
there are *NO* credible reports of the keyserver network being used to
distribute illegal data. Please don't think I'm crying that the sky is
falling, beca
On 5/27/12 6:53 AM, Gabor Kiss wrote:
> My idea: there shoud be five wise and trusted peoples -- i.e.
> a committee.
Theoretically possible, although it'd be very difficult to find five
people the entire PGP community could/would trust. As soon as you
introduce a committee of people with some kin
On 5/27/12 5:50 AM, Giovanni Mascellani wrote:
> I'm just a newbie here, but actually I'd like to see the same concept
> applied in a more general way: I think there is much garbage in the
> keyservers, even behind the PGP robo-signer.
The problem here is this violates one of the principle design
On 05/16/2012 01:12 PM, Kristian Fiskerstrand wrote:
> As upstream bandwidth capacity is one of the considerations that is
> taken into account in [0] I would appreciate if the server operators
> that have not already done so would kindly email me this information
> off list (My UIDs in 0x6b0b95
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 5/14/2012 9:41 PM, John Clizbe wrote:
> I hereby inquire as to the availability of source code for your
> release.
Although I'm neither an SKS maintainer nor a Debian SKS administrator, I
have to say the lack of source code confuses me. There a
On 05/11/2012 10:34 AM, Sebastian Urbach wrote:
> server name(s) to delete ?
keyservers.org, please. Thank you.
signature.asc
Description: OpenPGP digital signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/11/2012 05:02 AM, Phil Pennock wrote:
> The SKS peering mesh is built upon trust; in no small part, because
> the peering algorithm can cause load upon your peers. Recent
> events have forced me to re-evaluate two of my peerings.
I have nothi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/10/2012 06:34 PM, Arnold wrote:
> The readme says: "This ... version ... is intended to humiliate
> and expose the following persons"
Likewise.
More to the point, when using a precompiled binary one must trust the
good intentions of the packa
> You are very very confused: db-1.85 went end-of-life
> in like 1994
Not at all. That advisory, if you missed it, is from 2009.
I really don't care if db-1.85 was EOLed in 1994, 1984, or 1974. What I
care about is that it *is still used today* and there are, within recent
memories, reports of
On 04/29/2012 05:42 PM, Jeffrey Johnson wrote:
> If there were any BDB "security releases", you might have a point.
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-1436
Yes, that's actually a bug in the libc db interface, not BDB itself, but
the point still stands: this is something that
The other major problem with static linking is it forces the maintainers
to sync their releases with BDB security releases. If a defect is found
in BDB and sks is statically linked, a new sks has to be released. If a
defect is found in BDB and sks is dynamically linked, no new release of
sks need
On 04/21/2012 01:28 AM, Daniel Kahn Gillmor wrote:
> If the packaging meets debian quality standards, i think we can pretty
> easily get it into debian proper -- no need to host it on the google
> code download page.
I've never packaged for the Debian trees: I've only ever made .debs for
my own lo
On 4/20/12 2:22 PM, Daniel Kahn Gillmor wrote:
> I suspect the trickiest parts might be thinking about how to get a
> smooth upgrade from 1.1.1 and possibly how to deal with a transition
> to a newer version of bdb or ocaml. But i haven't looked into it
> beyond that.
Oh, ouch. Yes, I hadn't th
If we're in need of 1.1.3 packages for Debian and Debian-derived
distros, I might be able to help. My OCaml is no better than functional
(pardon the pun) and my knowledge of .debs is far from comprehensive,
but I have free time to devote to this.
At present I have zero interest in "taking over" f
On 04/20/2012 04:32 AM, Sebastian Urbach wrote:
> Just for everyone who depends on a debian sks package. I complained to
> the the debian project about Christoph Martin (Main Debian SKS
> developer) and im also trying to get him removed from that position as
> well.
This is unlikely to get the res
On 04/12/2012 09:33 PM, Phil Pennock wrote:
> "index.shtml" should probably go: that's for server-side includes, as
> processed by Apache and some other servers. The
> stuff, a bit like PHP or other inline scripting markup systems.
Speaking purely for myself, I've never seen .xhtm used as an ext
On 1/24/12 2:13 PM, Javier Henderson wrote:
> At what point (if any) is adding more peers to a given keyserver detrimental?
Impossible to say. There's a theorem in mathematics that makes it clear
two peers are sufficient for performance, and the more the merrier -- up
until the point your line ge
On 12/11/2011 8:55 PM, Daniel F wrote:
> Please see my response above. I am sorry if the proposal as is
> didn't make it patently clear, but it was originally written for
> people with the right context, and I failed to realize that there is
> that significant omission from the POV of a third-party
On 12/9/2011 12:36 AM, Daniel Kahn Gillmor wrote:
> I'm not sure this is OT on sks-devel, unfortunately, so it'll be my last
> post on-list on this thread.
Likewise, although I suspect here is as on-topic a place as we'll find.
>> http://privwiki.dreamhosters.com/wiki/Distributed_Web_of_Trust_Pro
> Reliable is *entirely* in the eye of the beholder.
Agreed.
> The core problem is extrinsic (as in dependent on the amount of
> data) interdependent tunables...
While I agree with your discussion of the external factors, I'd like to
point out that any modern database -- regardless of whether it
On 11/2/11 3:08 PM, John Clizbe wrote:
> One would need to ask Yaron to verify why BDB.
A former co-worker of mine used to play college football. One of his
engineering maxims came from his time on the gridiron: "if the instant
replay doesn't make the right call clearly obvious after three
watchi
On 11/2/11 5:49 AM, Andrey Korobkov wrote:
> Is there any chances that SKS would be ported to some other, more
> common databases like MySQL?
Berkeley DB isn't quite ubiquitous, but it's close.
> What is the reason behind choosing BDB as a storage?
It is exactly as much hammer as we need for the
On 10/15/2011 7:51 AM, John Clizbe wrote:
> I still think we have a ways to go to make SKS portable to more operating
> systems -- I think MacPorts provides the better framework than Fink to do this
> on OS X.
I belong to the "a pox on both their houses!" school myself, when
choosing between Fink
On 10/14/2011 1:39 AM, oakwhiz wrote:
> In my opinion, you're better off with a self-signed certificate,
> because you cannot trust the certificate authorities not to sign a
> fake certificate for use in a man-in-the-middle attack.
Although there are certainly some unreliable CAs (Diginotar as an
On 9/26/2011 10:51 AM, Timothy Holtzen wrote:
> Is it just me or is that not a valid key ID.
It's just you: it's a valid key ID.
A complete key ID is the same as the fingerprint of the key. A "short
ID" is the final eight hexadecimal digits of the key; a "long ID" is the
final sixteen; a "full I
On 9/23/2011 5:48 PM, Timothy Holtzen wrote:
> Thanks for the suggestions. Assuming signing worked on this
> message, turning on PGP/MIME seems to have resolved the issue.
Looks good. As a word of warning, though, PGP/MIME is known to *not*
work with older versions of Mailman. Older version
(I hate to sound unhelpful: it's only because I'm presently @work and
can't spare the time to give this the full attention it deserves. Expect
more later.)
John, although I heartily approve of what you're trying to do, your page
does not pass the W3C's validation tests:
http://validator.w
On 8/29/11 2:17 AM, Phil Pennock wrote:
> After seeing Samir's suggested index.html page, I decided to make a few
> updates to my own. It's a nasty competitive streak that sometimes comes
> to the fore.
Although I don't mean to dissuade anyone from following their muse, why
HTML5? Wouldn't 401+C
1 - 100 of 134 matches
Mail list logo
