On Wed, 30 May 2012 16:16, r...@sixdemonbag.org said:
> On 05/30/2012 09:40 AM, Mark H. Wood wrote:
>> Oh, how many times have I wondered why GPA has no search tool.
>
> Taking a look at GPA, it seems that 0.9.0 no longer compiles on a modern
> UNIX -- it expects libassuan-1.x, apparently, and liba
On 05/30/2012 09:40 AM, Mark H. Wood wrote:
> Oh, how many times have I wondered why GPA has no search tool.
Taking a look at GPA, it seems that 0.9.0 no longer compiles on a modern
UNIX -- it expects libassuan-1.x, apparently, and libassuan's now in a
version 2.
I wasn't able to get the git chec
On Tue, May 29, 2012 at 09:23:08PM +0200, Werner Koch wrote:
> On Tue, 29 May 2012 19:44, r...@sixdemonbag.org said:
>
> > Anyway. If people are interested in what I found out about effective
> > user-interface design with respect to certificate managers, say the
> > word. Otherwise I'll crawl b
On Tue, May 29, 2012 at 10:03:57PM -0400, Robert J. Hansen wrote:
> There may be a use case for contextualization in certificates, but if so
> I haven't found it yet. :)
You may wnat to lookup up all certificates that signed a certificate.
Or just get all your certificates displayed.
Or all cert
On 5/29/12 9:57 PM, reynt0 wrote:
> In general, being able to examine variation of content within
> uniformity of structure is also a way to legitimate the
> specific content of interest.
As I said, it's useful when data must be contextualized. For a
spreadsheet, the information in one row must b
On Tue, 29 May 2012, Robert J. Hansen wrote:
. . .
Tabular data is the Right Thing To Do in two major use cases.
The first is when you have a noninteractive display of identical
field(s) for multiple pieces of data. Consider a printed almanac: if it
wants to convey a list of countries and popu
On May 29, 2012, at 3:34 PM, Daniel Kahn Gillmor wrote:
> On 05/29/2012 02:18 PM, David Shaw wrote:
>> The reason I bring it up is that using the v3 key attack, 64-bit key IDs
>> have no particular benefit over 32-bit IDs for intentional collisions (i.e.
>> an attacker generating a key with the
On 5/29/12 3:23 PM, Werner Koch wrote:
> However, changing such a common UI might result in a
> lot of negative comments - people love what they once learned.
Absolutely. The good news, though, is that (at least in the Free
Software world) the 'market' is fragmented. No one particular key
manage
On 05/29/2012 02:18 PM, David Shaw wrote:
> The reason I bring it up is that using the v3 key attack, 64-bit key IDs have
> no particular benefit over 32-bit IDs for intentional collisions (i.e. an
> attacker generating a key with the same key ID as the victim in order to
> confuse matters and/o
On Tue, 29 May 2012 19:44, r...@sixdemonbag.org said:
> Anyway. If people are interested in what I found out about effective
> user-interface design with respect to certificate managers, say the
> word. Otherwise I'll crawl back under my rock and leave the subject
GPA has many different ways to
On May 29, 2012, at 2:05 PM, Sam Whited wrote:
> On Tue, May 29, 2012 at 1:47 PM, David Shaw wrote:
>> On May 29, 2012, at 11:51 AM, Daniel Kahn Gillmor wrote:
>>
>> What is your concern here, though - accidental or intentional collision?
>
> Certainly both; while accidental collision isn't pro
On Tue, May 29, 2012 at 1:47 PM, David Shaw wrote:
> On May 29, 2012, at 11:51 AM, Daniel Kahn Gillmor wrote:
>
> What is your concern here, though - accidental or intentional collision?
Certainly both; while accidental collision isn't probable, 32-bit IDs
aren't exactly collision resistant eithe
On 5/29/12 1:44 PM, Robert J. Hansen wrote:
> According to Google's HCI guys [2], 90% of the U.S. internet-using
> population doesn't know how to use Control-F to find a word in a
> document or a page.
Whoops, editing error. Should've been footnote [1], and I should've
listed it as:
http://www.
On May 29, 2012, at 1:18 PM, Werner Koch wrote:
> On Tue, 29 May 2012 18:31, r...@sixdemonbag.org said:
>
>> Honestly, this seems like something to bring up to the IETF WG. The RFC
>> already has a plethora of implementation recommendations: adding an
>> implementation recommendation of "use lon
On May 29, 2012, at 11:51 AM, Daniel Kahn Gillmor wrote:
> On 05/29/2012 11:35 AM, Werner Koch wrote:
>> Use
>>
>> gpg --keyid-format long --decrypt sensitive_file.gpg
>>
>> to see the non-abbreviated key ID as stored in the file. Use this to
>> find the key on a server, etc.
>
> i've seen
On 5/29/12 1:18 PM, Werner Koch wrote:
> Frontends should handle this problem.
The problem is that most people developing front ends are making them
pretty darn user-hostile.
A few years ago while taking some HCI courses, I did a usability study
on the most common certificate interface -- the tab
On 5/29/2012 10:18 AM, Werner Koch wrote:
> Hiding the keyID from the user would even be better - the mail
> address should be sufficient for 99% of all users.
I use the e-mail address for almost all of my command-line work, FWIW.
--
If you're never wrong, you're not trying hard enough
___
On Tue, 29 May 2012 18:31, r...@sixdemonbag.org said:
> Honestly, this seems like something to bring up to the IETF WG. The RFC
> already has a plethora of implementation recommendations: adding an
> implementation recommendation of "use long key IDs when possible" seems
I bet that this will imm
On 5/29/12 11:51 AM, Daniel Kahn Gillmor wrote:
> Perhaps GnuPG should change the default of --keyid-format from "short"
> to "long"?
Hurts interoperability. Once someone learns the process on PGP or
BouncyCastle or [insert OpenPGP implementation here], they're going to
want to take those same sk
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2012-05-29 17:51, Daniel Kahn Gillmor wrote:
> On 05/29/2012 11:35 AM, Werner Koch wrote:
...
> I think switching the default to "long" would be on balance a Good
> Thing.
>
I agree, and don't see much of a reason not to use a long KeyID rathe
Am Di 29.05.2012, 11:51:06 schrieb Daniel Kahn Gillmor:
> I think switching the default to "long" would be on balance a Good Thing.
A smaller change which should "solve" most of these problems could be to
change the error message. If gpg is operating with the short format then a
respective hint
21 matches
Mail list logo
