On 27/12/2018 10:35, Matt Palmer via dev-security-policy wrote:
> Hmm, Rob's reply never made it to my inbox.  I'll reply to that separately
> now I know it's a thing.

Hi Matt.  I'm consistently receiving "Undelivered Mail Returned to 
Sender" messages from your mailserver, which is presumably why you 
didn't see my reply.  The body of each message is as follows:


This is the mail system at host mail.hezmatt.org.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                    The mail system

<mpal...@hezmatt.org>: Command time limit exceeded: "exec 
/usr/bin/procmail -t
     -a "${EXTENSION}""


> On Thu, Dec 27, 2018 at 05:56:08PM +0900, Hector Martin 'marcan' via 
> dev-security-policy wrote:
>> On 19/12/2018 20:09, Rob Stradling via dev-security-policy wrote:
>>> I'm wondering how I might add a pwnedkeys check to crt.sh.  I think I'd
>>> prefer to have a table of SHA-256(SPKI) stored locally on the crt.sh DB.
>>
>> Yes, I think the right approach for an upstream source is to provide a big
>> list of hashes. People can then postprocess that into whatever database or
>> filter format they want.
> 
> The reason I haven't provided that (yet) is because, unlike pwnedpasswords,
> the set of pwned keys increases in real-time, as my scrapers go out into the
> world and find more keys.  Thus, a once-off dump of what's in the database
> today isn't going to be very useful tomorrow, or next week, or next month.
> 
> I don't want to put up a dump of everything until I've got a solid mechanism
> for people to retrieve and load updates of the dataset.  The last thing I
> want to do is give people any encouragement to use a stale data set.
> 
> Implementation of an auto-update mechanism is on the todo list, but it's
> quite a bit lower down the priority list than other things, like improving
> key scraping, and implementing a bloom filter of keys, which I feel is more
> useful, because you've got to hit the API anyway to get the attestation of
> compromise, so something with a bit of a false-positive rate isn't a big
> deal.
> 
> - Matt

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to