Paul Wise wrote (24 Dec 2013 05:49:34 GMT) : > The author claims it has an advantage over parcimonie of using > unique Tor circuits for each key fetch. Personally I don't think > bash is the appropriate language to implement this though.
> https://github.com/EtiennePerot/parcimonie.sh Indeed, the author writes: "Unlike the original Parcimonie, parcimonie.sh guarantees that each key refresh happens over a unique Tor circuit even when multiple refreshes happen at the same time. (How?)" I find this phrasing slightly confusing and potentially misleading, but still, what I believe it really means is entirely correct: while parcimonie does not do multiple refreshes at the same time, indeed, if the user *manually* triggers a key refresh on their own, it may very well used the same circuit that parcimonie (has used last|is using right now|will be using next time). This feature would be trivial to add to parcimonie (not writing "the original parcimonie", as IMHO it's the responsibility of the other implementation to not reuse an identifier that's already taken in the global namespace, not mine to differentiate from his). (OT: I was thinking last night of getting rid of the DBus bits in parcimonie, and instead implement a way for the daemon to report the success/failure details in a computer-readable format on stdout, and have the applet 1. run the daemon itself 2. read its stdout 3. present it to the user. This would probably be more lightweight both in terms of memory footprint, and in terms of the size of the codebase that one may want to audit and/or trust.) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85eh52eh2w....@boum.org
