[Sks-devel] sks patch to refuse poison key
On Sun, Jul 15, 2018 at 06:28:24PM +1000, Haw Loeung wrote: > I don't think these patches should land in SKS. It's to work around > one key and doesn't scale very well. Instead, I think more work should > be done adding the ability to not accept and send keys of a certain > size as well as options to exclude specific list of keys. I'm not sure > if there's another mailing list used by SKS developers to discuss > this. Thanks, I see the patches hard code key id, so I think it shouldn't land in upstream too. > > If you're interested in the patches, you should be able to download > the *.debian.tar.xz file from the link below: > > | > https://launchpad.net/~canonical-sysadmins/+archive/ubuntu/sks-public/+packages > > Extract that and the series of patches to-date are: > > | 0012-poison-key.patch > | poison-key-id-update > | 0014-poison-key-output-fix > | 0091-pjdc-compare-short-keyid.patch > I don't know ocaml, but these patches are in a mess, shouldn't it be simplified to, diff --git a/keydb.ml b/keydb.ml index 949a1f4..7ff976a 100644 --- a/keydb.ml +++ b/keydb.ml @@ -1166,6 +1166,11 @@ struct try if has_hash hash then [] else let keyid = Fingerprint.keyid_from_key ~short:true key in +let keyid_long = Fingerprint.keyid_to_string ~short:false (Fingerprint.keyid_from_key ~short:false key) in + +(* Blacklist poison key - RT#112669 *) +plerror 4 "considering keyid %s" keyid_long; +if List.mem keyid_long ["E41ED3A107A7DBC7"] then [] else let potential_merges = List.filter ~f:(fun x -> x <> key) (get_by_short_keyid keyid) in -- Best regards, Shengjing Zhu signature.asc Description: PGP signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] withdrawal of service: sks.spodhuis.org
Hi Tom,
I spend the night on the keydump - keys.flanga.io is now also running
with hockeypuck (I did not test anything to be honest though ;)). I'll
see if it runs stable (not sure if it is pool compatible) - version is
1.1.6.
A short write-up for installing this thing is already done - I can send
the link if it works ;)
The server is only peering with my own instances right now - however it
looks like recon has a problem with the filters of sks (which should not
be a big deal)..
{filters do not match.\n\tlocal filters: [ yminsky.dedup yminsky.merge
]\n\tremote filters: [ yminsky.dedup yminsky.merge ]} {remote rejected
configuration}]" label="serve :11370"
Best regards,
Moritz
Am 15.07.18 um 04:31 schrieb Tom at FlowCrypt:
> > Does anyone in the pool run hockeypuck? How compatible is its
> recon with others running sks-keyserver?
>
> Yes, here is one: http://keyserver.snt.utwente.nl
>
> (see https://sks-keyservers.net/status/
> and http://keyserver.snt.utwente.nl:11371/pks/lookup?op=stats )
>
> However, it was kicked out of the pool because "SKS version < 1.1.6"
> as
> per
> https://sks-keyservers.net/status/ks-status.php?server=keyserver.snt.utwente.nl
>
>
> It does seem to be syncing well - key diff 1,385 looks great to me
> even compared to servers that are in the pool.
>
> I'm adding Robert in copy in case he's able to share his experience
> running the Hockeypuck server. Robert, if this email can reach you,
> We'd be interested to know how is the server coping with recent issues
> that were affecting the SKS network? How stable do you find Hockeypuck
> overall, how much dev-ops do you need to do?
>
>
>
>
> On Sun, Jul 15, 2018 at 1:21 AM, Haw Loeung > wrote:
>
> On Sun, Jul 15, 2018 at 11:17:20AM +1000, Haw Loeung wrote:
> > On Fri, Jul 13, 2018 at 07:53:01PM +0100, Andrew Gallagher wrote:
> > > I am still willing to help with possible upgrades and/or
> > > replacements for the SKS network. At this point I have come to
> > > believe that a minimal network containing only key material,
> SBINDs
> > > and revocations (no id packets, no third party sigs) is the
> absolute
> > > maximum functionality we can hope to sustain in the long term. And
> > > for this to be bulletproof, all such material must be
> > > cryptographically verified (otherwise people could just create
> > > “random” key material containing arbitrary data).
> >
> > If it helps others, we have a patched SKS packaged to exclude
> the bad
> > key (one of them at least)[1]. A couple of others in my team did all
> > the work so I can't comment on the details.
> >
>
> I should also add, you'll then need to drop the key from the DB with:
>
> $ sks drop 8C070D00D81E934B3C79247175E6B4BC
>
>
> Regards,
>
> Haw
>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
>
>
>
>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
signature.asc
Description: OpenPGP digital signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] withdrawal of service: sks.spodhuis.org
Just saying... ...the person who created that key has finally started a long overdue process. They are likely reading this as well, so: Thank you. This could otherwise have ended much worse. To the other readers, but only to those of them who do not agree with the following sentences: Please avoid trying to fix symptoms. Go for the root issue, even if it hurts. Don't deny that it does; the whole design of what you have been taking for granted when you learned about PGP needs to be fundamentally rewritten. Until that has happened, I personally believe that every (!) key server administrator should shut down their keyservers, with no exception. Users, especially commercial ones, are very welcome to notice the impact of the sudden lack of a convenient, free service provided as a voluntary donation by people who are risking their freedom and risking going to jail, on the users' daily work. Users are very welcome to finally notice the problem as well, and users are very welcome to contribute suggestions and code to the further fixing of the fundamentally flawed keyserver network design. My personal suggestion: Complete pool shutdown until the underlying problem is completely fixed. If it can't be fixed, keep the pool offline. It has been a good, happy time, and one of the next steps can (doesn't have to!) be realizing that it has irrevocably reached its end. PGP works without keyservers, by the way. It can't be bad for users to finally learn how. Best regards Tobias Frei ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] Berkley DB Logs
Hi sks-Guys, I know, there are already discussions about getting rid of the many Berkley DB logs. Furthermore, I would like to ask you all for the best practise or YOUR best practise for standard maintance jobs (cronjobs etc.) during operating of sks keyservers. Best Regards Fabian 'otih' pgplxTAMCeJmQ.pgp Description: Digitale Signatur von OpenPGP ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
