The folder search implementation in the custom query parser is always rooted
(both because that happened to be much easier to do in that design, and
because I agree with you that rooted searches seem preferable most of the
time). What arguments do people have for or against rooted folder searches?
"Daniel A. Nagy" writes:
>generating a new key with the same 64-bit key ID as an existing key is on the
>very far end of the realm of feasibility.
That should be:
generating a *secure* new key with the same 64-bit key ID as an existing key
is on the very far end of the realm of feasibility.
Jon Callas writes:
>On the other hand, this has never been a problem. It's harder than you think,
>because you have to generate a new key each time, which takes a while on RSA.
Only if you want a secure key. For SSH fuzzy fingerprinting the limiting
factor is the hashing, not the rate at which
Carl Worth writes:
> This works in a similar way to 'subject:"some phrase"', (though more
> people seem to be asking about these details for folder: than have ever
> asked for subject:).
I'm not surprised. Imagine:
/misc
/debian/misc
If I understand correctly, right now you'd have to say
On Jan 17, 2011, at 8:47 PM, Daniel Kahn Gillmor wrote:
> Would there be any objection to a new subpacket type for OpenPGPv4 that
> would include the remaining 96 bits of the issuer's fingerprint? (the
> "high 96" proposal)
>
> Alternately, what about a new subpacket type that simply includes th
On 01/18/2011 02:47 AM, Daniel Kahn Gillmor wrote:
> i believe collisions of the low 64 bits of SHA1 are within reach today,
> i'd love to be corrected if this is not the case
I'd suggest using the entire fingerprint as a reference and leaving the
creation date out of the fingerprint calculation f
Jon Callas writes:
>On the other hand, this has never been a problem. It's harder than you think,
>because you have to generate a new key each time, which takes a while on RSA.
Only if you want a secure key. For SSH fuzzy fingerprinting the limiting
factor is the hashing, not the rate at which
On the one hand, my only disagreement with you is to suggest that your proposal
be tied into using SHA256 for a fingerprint. If you're going to expand the
keyid to a fingerprint, why not get a better fingerprint?
On the other hand, this has never been a problem. It's harder than you think,
beca
On Tue, 18 Jan 2011 13:54:29 -0600, Rob Browning wrote:
> I'd be tempted to consider making folder: searches rooted by default. I
> wonder how often people really want "all folders named misc"?
That's a possibility---*after* someone does the work to enable rooted
searches in the first place.
-C
earches in the first place.
-Carl
--
carl.d.worth at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110118/2fe5c356/attachment.pgp>
Carl Worth writes:
> This works in a similar way to 'subject:"some phrase"', (though more
> people seem to be asking about these details for folder: than have ever
> asked for subject:).
I'm not surprised. Imagine:
/misc
/debian/misc
If I understand correctly, right now you'd have to say
On Mon, 17 Jan 2011 12:48:11 -0600, Rob Browning wrote:
> Nice.
Thanks.
> So what are the path semantics? For example, is the path case
> sensitive or insensitive? Can you say folder:foo/bar, and if so, is the
> path rooted, or can it match path sub-segments?
>
> i.e. which of these, if any,
scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110118/d31c1d7d/attachment.pgp>
was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110118/0c50f62d/attachment.pgp>
14 matches
Mail list logo
