Forum for the FireGPG's extention. (!Don't post too links or wait we unban your, akismet is very aggressive)
You are not logged in. Please login or register.
FireGPG Forum » Posts by dkg
Pages 1
Thanks for directing me to it.
I've just created a patch for the CreateZipFile class, and alerted the author of the original class so that they can incorporate it so that future users don't get the weird timestamps.
Feel free to apply that patch to your locale generation system; it should set the zipfile elements to the current timestamp by default.
Let me know if you have any trouble.
I just filed task 269, thanks!
If you point me toward the PHP code you use to generate the locales, it's possible that i could give you a patch so you don't have to think about it any more.
I've contacted him a couple times this week, but i've gotten no response yet.
The firegpg package was just recently removed from debian for being out-of-date and insecure, and i'm trying to rectify that.
While i understand your suggestion of unpacking things while deliberately ignoring certain errors, much of the automated build processes where an updated package would get rebuilt in debian do not give me that level of control. However, even if i did have that level of control, i think i woudn'td want to do it that way; the problem is that the timestamps are erroneous, and it makes more sense to me to correct them than to mask the warnings that they're clearly wrong.
how do you create a zip file without a date in the first place? i could find no such option in zip(1).
I'm trying to create a maintainable build process for firegpg for debian (and its derivatives). The build process involves unpacking the tarball, as as it is the canonical source i'm working from. Having extra noise in the build process obscures real errors which i'd rather know about.
Won't svn detect changes based on the contents of the directory, not just the timestamps? Or even if it doesn't, wouldn't having the proper timestamps (e.g. right now) be sufficient for your purposes of alerting svn of the changes?
I agree, it's not a hard error. But to be clear, it's not just a warning either. It's actually 330 warnings each time the tarball is unpacked., which is a lot of noise. It would be one thing if the timestamps were just missing (i don't know how the tar format would represent that), but it looks to me like the timestamps are actually, specifically, wrong.
It seems like there is an obvious semantic choice for what the timestamp for any given locale should be: just the date that you last updated it, no? Is there any reason not to do that, if it's possible?
Can you describe how you update the locales? Maybe i can help find a way to get the timestamps set to a reasonable value with no extra inconvenience for you. I'd like to help!
I've been playing around with the source tarball for firegpg, and i noticed that the timestamps for most of the locale files seem to be: 2038-01-19 03:14:07
(this is the wrap-around date for time_t, so i suspect a bug or something). It seems to be this way within chrome/firegpg.jar (inside firegpg.xpi) as well.
Could this be cleaned up somehow? It causes quite a bit of unnecessary warnings. Should i file it as a bug report?
> Why?
The way i see it: if a protocol has no active upstream support, no advocate, no formal specification, no development community, and no way of responding to reasonable concerns, then implementations of that protocol probably do not belong in a piece of user-facing security-critical software. At least not without big shiny red warning flags all around any and all UI related to where it might actually be used (and even that should only be possible after ticking a checkbox that can only be found in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard') 
> No.
It seems like Enigform and FireGPG do some similar (though certainly not identical) tasks. They both do some incredible work behind the scenes to help Firefox talk to GnuPG, both potentially deal with Web of Trust issues, both ask the user for their GPG passphrase, and both deal with potential signing of sensitive data. Why not talk to each other and share notes at least?
I found a discussion on enigform's forum that suggests that Kyle Huff (the original gpgAuth author) is proposing abandoning gpgAuth entirely in favor of enigform and apache's associated mod_auth_openpgp. another post suggests that he has in fact joined the enigform team As such, i plan on moving my cryptographic review to that suite of tools, and suggest that people avoid using gpgAuth entirely unless more information is forthcoming.
If you don't know how to reach the gpgAuth author, and he seems to have abandoned his own project, perhaps support for gpgAuth should be dropped from FireGPG ? Are you guys in discussion with buanzo (the author of enigform) about the ways your respective tools could work together?
Thanks for your quick followup, the_glu. If i find anything out that's relevant to firegpg, i'll post it here.
I've tried to contact the author by posting on the forum, but didn . do you have another way i should contact him or her? whois suggests that he's named "kyle huff", but the main kyle huffs i found online was someone who went on shooting rampage in seattle a few years ago 
And i'm concerned not just that gpgauth is spoofable (i wouldn't trust it anyway), but that gpgauth support in firegpg could potentially allow for abuse of the user's keyring by a remote server which prompts for gpgauth activity.
can you explain more about why that wouldn't be a risk for users of firegpg?
I recently raised significant problems and concerns with the gpgauth protocol on the gpgauth forums, and only got a response from someone who does not appear to be an author of the site.
Is fireGPG's gpgauth support vulnerable to the concerns i raised there?
Pages 1
FireGPG Forum » Posts by dkg
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 2 official extensions. Copyright © 2003–2009 PunBB.