Re: High resource usage when verifying a signature
On 19.07.15 20:22, Crissy Lynn wrote: > Please remove me from this mailing list. Please follow the link at the bottom of each list email and follow instructions. -- Ville signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [slightly off topic] e-courier.ca
On 18.07.15 17:21, Philip Neukom wrote: > I put "secure" in quotes as they talk about a "proprietary" encryption > algorithm. As soon as I read "proprietary", I have to roll my eyes as I > don't necessarily trust encryption if it isn't open for everyone to verify. Pretty much. > Is this similar to what has been discussed as a potential use or service > by GnuPG? The service isn't seamless but perhaps would make sense as an > offering by GnuPG/Werner? No. There is a standard called OpenPGP already and this service is not relevant in any way. See the how it works page[1]. They can't and don't change how email, i.e. SMTP works. They just send the receiver a link to their web service and both their client and recipient use a browser to do their "emailing". The world is full of services like that. GnuPG and other OpenPGP compliant software sign and / or encrypt the /contents of email/. [1]: http://e-courier.ca/howitworks.html -- Ville signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: speedo build of 2.1.6 failing on OS X
On 18.07.15 07:38, NIIBE Yutaka wrote: > On 07/18/2015 03:04 AM, Ville Määttä wrote: >> $make -f build-aux/speedo.mk native INSTALL_PREFIX=/usr/local/gnupg >> CC=/usr/local/bin/gcc-5 CXX=/usr/local/bin/g++-5 > [...] >> Undefined symbols for architecture x86_64: >> "_gettext", referenced from: > > I think that it is related to NLS (Natural Language support). > > Please see the issue: > Non-NLS build broken in 2.1.6 > https://bugs.gnupg.org/gnupg/issue2032 > > It is fixed in master branch. > That was it. Thanks. -- Ville signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
speedo build of 2.1.6 failing on OS X
I'm getting a failure at speedo.mk build for 2.1.6 on OS X 10.10.4 Yosemite. I'm using a forced brewed GCC 5.2, that is: $make -f build-aux/speedo.mk native INSTALL_PREFIX=/usr/local/gnupg CC=/usr/local/bin/gcc-5 CXX=/usr/local/bin/g++-5 It's failing at gpg-agent. Just the short snippet below. I just built 2.1.5 with the same setup and previous builds have also built ok. Is anyone else seeing this? Making all in agent CCLD gpg-agent CCLD gpg-protect-tool CCLD gpg-preset-passphrase Undefined symbols for architecture x86_64: "_gettext", referenced from: _ssh_handler_add_identity in gpg_agent-command-ssh.o _agent_Lunderscore in gpg_agent-call-pinentry.o _setup_qualitybar in gpg_agent-call-pinentry.o _agent_delete_key in gpg_agent-findkey.o _check_passphrase_constraints in gpg_agent-genkey.o _agent_ask_new_passphrase in gpg_agent-genkey.o _agent_genkey in gpg_agent-genkey.o ... ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status make[4]: *** [gpg-agent] Error 1 make[4]: *** Waiting for unfinished jobs make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 make[1]: *** [/Users/vmaatta/src/gnupg-2.1.6/PLAY/stamps/stamp-gnupg-02-make] Error 2 make: *** [native] Error 2 -- Ville signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Yubikey NEO OpenPGP advisory
On 27.04.15 12:43, MFPA wrote: >> Right now, they're rolling out a payment system here in >> > The Netherlands where you only need to tap your bank >> > card to the payment terminal to do small payments. >> > That's all that is needed. > We have that in the UK already. Payments up to, I think, GBP20 > without PIN or signature. Dangerous. Yep, EUR 25 max here in Finland if I recall correctly without PIN and "random PIN check" once in a while… I suppose the banks get a warm and fuzzy "we've done something" feeling from the random checks. Roll-out started about a year ago I think. >> So I'm still looking for a sturdy yet practical >> metallic sleeve to put around the bank card as soon as >> they replace my non-NFC card with an NFC card . The >> one I've seen looked to finnicky to remove your bank >> card from, which you do every time you need to pay in a >> shop... > > Some of the ones brought up by a search on "rfid card wallet " look > just like an ordinary wallet. And I'm sure a small metallic business > card holder or cigarette case would do the trick. I have the basic blocking wallet from ThinkGeek [1] and it's just like a normal wallet. They seem to have a new one as well although both out of stock right now. [1]: https://www.thinkgeek.com/brain/whereisit.cgi?t=rfid+wallet -- Ville signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: PGP/MIME (Was: One alternative to SMTP for email: Confidant Mail)
On 25.03.15 22:32, Doug Barton wrote: > On 3/25/15 1:20 PM, Ville Määttä wrote: >> On 25.03.15 21:41, Doug Barton wrote: >>> While this is strictly anecdotal evidence I would argue that it's a good >>> indication that we may not be ready for PGP/MIME as the default. >> >> I think that fail, a signature.asc attachment, is still a "cleaner fail" >> than a non-PGP receiver getting a breakdown from inline PGP. And that is >> for every single email. > > How are you using the term "breakdown" here? If their client isn't doing > PGP they see some extraneous text, and a signature block. While I agree > that for those not using PGP that is clutter, I am not sure what you > mean by "breakdown." That's a "mental breakdown" of the user :). Sorry about the ambiguity. > >> I have not received a single question from anyone regarding my PGP/MIME >> signed emails. Not one. And I'm talking about the ones that don't use >> PGP / have no clue what PGP is. > > We've already established that PGP/MIME is a "cleaner" solution for those > that don't use PGP. I'm not debating that point, and I don't think anyone > else is either. I suppose I must've missed that we had established that… > The question at hand is for those that *do* use PGP, which is more effective? > TMK there are no mail clients that fail to process a valid in-line signature, > but obviously there are still clients that cannot correctly handle PGP/MIME. True. I consider both inline and PGP/MIME equally to be something of a MUST support for any client / plugin that claims to support PGP. Whether support is done by the client itself or a plugin is not that important to me as long as someone is maintaining support. -- Ville signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: PGP/MIME (Was: One alternative to SMTP for email: Confidant Mail)
On 26.03.15 01:38, Daniele Nicolodi wrote: > On 25/03/15 23:56, Ville Määttä wrote: >> > On 26.03.15 00:14, Ingo Klöcker wrote: >>> >> So it's not mailman that's not smart enough, but the mail clients >>> >> the other recipients are using. Mail clients showing a >>> >> "signature.asc" attachment probably do not understand PGP/MIME >>> >> (which isn't that unusual because only a handful mail clients >>> >> support PGP/MIME out-of-the-box without additional plugins). >> > >> > It seems to me that emails sent and signed by Thunderbird + >> > Enigmail are displayed just fine by it. No signature.asc quirks. >> > But emails sent by others are displaying the attachment in addition >> > to the normal Enigmail added UI signature information. Ingo, Doug, >> > Samir and Bob; I see the attached file for each of you but not my >> > own PGP/MIME mails routed back to me from the list :). > The difference must be somewhere else: I use Thunderbird 31.5.0 and > Enigmail 1.8 (20150316-1815) and, while it recognizes the signatures, > I see the attachment "signature.asc" for all the PGP/MIME signed > emails I've checked. I sent a signed message to Daniele off list. Signature recognized fine and no attachment. So a bug, i.e. the extra attachment, in Enigmail's reading of mails that have gone through Mailman even though Mailman produced MIME should be valid? -- Ville signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: PGP/MIME (Was: One alternative to SMTP for email: Confidant Mail)
On 26.03.15 18:17, Brian Minton wrote: > I think gmail is the single most popular email client, with 500 million > > users. There are about 7,3 billion people out there that don't have a clue what OpenPGP is. > I think that until there is a way to verify pgp signatures from > > within gmail, pgp/mime will continue to show up as an attachment. Why should it? At least for non-Gmail users as well as Gmail users not using *webmail*. > There are ways to use pgp/mime or inline pgp with gmail, but nothing > > great. I'm hopeful for google's end to end, and I currently use > > mailvelope, but as far as I know, neither of those options supports > > PGP/MIME. Yeah… so? Not all email users are GMail users. Not all GMail users use the /webmail/ interface. There are a lot of GMail and other /webmail/ users out there but *we really need to stop letting that drag us down*. Those /webmail/ operators need to get their shit together and start playing by the rules. It's not our job to do theirs for them. And until OpenPGP breaks out even of the single digits coverage I really don't think we should worry about every single use case. Those who care for OpenPGP can very easily just use something other than webmail. I just did a test across accounts sending from Thunderbird + Enigmail. Sure, GMail /webmail/ shows the attachment. In Thunderbird over IMAP the emails are just fine; "Good signature" and no attachments. Now Google just needs to go and get their platform up to speed on PGP/MIME. -- Ville signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: PGP/MIME (Was: One alternative to SMTP for email: Confidant Mail)
On 26.03.15 00:14, Ingo Klöcker wrote: > So it's not mailman that's not smart enough, but the mail clients the other > recipients are using. Mail clients showing a "signature.asc" attachment > probably do not understand PGP/MIME (which isn't that unusual because only a > handful mail clients support PGP/MIME out-of-the-box without additional > plugins). It seems to me that emails sent and signed by Thunderbird + Enigmail are displayed just fine by it. No signature.asc quirks. But emails sent by others are displaying the attachment in addition to the normal Enigmail added UI signature information. Ingo, Doug, Samir and Bob; I see the attached file for each of you but not my own PGP/MIME mails routed back to me from the list :). -- Ville signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
PGP/MIME efficacy (Was: Weird error during key refresh)
On 25.03.15 21:42, Doug Barton wrote: > > Doug > > -- > I am conducting an experiment in the efficacy of PGP/MIME signatures. > This message should be signed. If it is not, or the signature does not > validate, please let me know how you received this message (direct, or > to a list) and the mail software you use. Thanks! It seems I'm getting all (ok, sample size 2) your emails as "good signature" and with signature.asc attachment. -- Ville signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: PGP/MIME (Was: One alternative to SMTP for email: Confidant Mail)
On 25.03.15 21:41, Doug Barton wrote: > While this is strictly anecdotal evidence I would argue that it's a good > indication that we may not be ready for PGP/MIME as the default. I think that fail, a signature.asc attachment, is still a "cleaner fail" than a non-PGP receiver getting a breakdown from inline PGP. And that is for every single email. I have not received a single question from anyone regarding my PGP/MIME signed emails. Not one. And I'm talking about the ones that don't use PGP / have no clue what PGP is. > FWIW, I have received various other messages privately from people who have > said the same thing ... They can see the attachment, but either message > verification fails, or there is no indication on their side that it is a > PGP-signed message at all. In this one I can see your email with the attachment, but also marked with a "good signature". -- Ville signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Email-only UIDs and verification
On 20.03.15 20:47, Daniel Kahn Gillmor wrote: > On Fri 2015-03-20 13:43:27 -0400, Bob (Robert) Cavanaugh wrote: >> > One thought to add to the mix: Phishng attacks by having >> > unknowledgable users "click on this link" are pretty >> > successful. Doesn't this proposal open a new threat vector? Yeah… I don't really see much of a problem as proposed by Bob. Any verification emails for any purpose should always be related to an action the user did very recently. I.e. they visited a site or used an application, whatever the route and method but they should already /be expecting an email verification/. > If the followup is just "click this link" then i agree it's probably > encouraging bad habits. Any verification should certainly be worded better, yes :). > What if the suggested followup was an e-mail > reply? What if we require the verifier to sign its outbound messages, > and tell users "don't do this unless the message is signed by the > verifier"? Good ideas. -- Ville signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: bugs.gnupg.org TLS certificate
On 13.03.15 15:27, Werner Koch wrote: > The more expensive CAs are only selling you a fashionable background > color for your the client's address bar. Essentially, that's it :). There are however clearly defined hard requirements to the Extended Validation, aka "green bar" level. That is, more involved validation of the organization and the person requesting the certificate. But those EV certs can be had for cheaper than hundreds of dollars per year. -- Ville signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: bugs.gnupg.org TLS certificate
On 13.03.15 15:04, Mark H. Wood wrote: > On Fri, Mar 13, 2015 at 05:55:53AM -0300, Hugo Osvaldo Barrera wrote: >> > On 2015-03-13 08:21, Werner Koch wrote: >>> > > On Fri, 13 Mar 2015 00:21, h...@barrera.io said: >>> > > > > > No need for a wildcard one. Just get one free certificate for each > > > subdomain > > > from StartSSL. >>> > > >>> > > Definitely not. It far easier to pay 10 Euro a year for one from >>> > > Gandi. But that is all not an issue, migrating Roundup to a newer >>> > > version is more work. >>> > > >>> > > >> > >> > I don't see what's easier (maybe it takes a few minutes less?), nor the >> > point >> > in paying for something you can have for free with the same quality. > That is precisely the issue with free or even cheap certificates: > they are likely *not* of the same quality. > > A few years ago, I ordered my first certificate from a well-known CA. > They charged us $159.00. I *know* that they check up on new > applicants: our security officer got a phone call from them, asking if > I was legitimately representing the organization. That certificate > certified more than just "probably the same host that presented this > certificate to you last time." The CA cartel has specified clear and binding rules for the participating CAs as to what level of validation is required. This is overly simplified but they are essentially: Domain validation (Class 1) Organization validation (Class 2) Extended Validation (Class 3) Any automatically validated, i.e. some file on a URL or DNS check etc. is a Class 1 cert. The rest require filing paper work and usually take from hours to days to complete. And there is no reason for anyone to try guessing which level a cert belongs to, they tell you the validation beforehand. > A CA that charges nothing cannot afford to do much (any?) checking of > the assertions in my CSR. … > A free cert. may have all of the qualities that you need, but I > recommend that you think as carefully about your choice of CA as you > do about who you would have sign a PGP key. Many CAs will be happy to sell a Class 1 certificate for 100-200$ or more. Paying money for a cert doesn't necessarily make it any more "certified". The CA business is a badly monopolized cartel where the old farts have dug in years ago and are just counting the money :). Am Organization cert is the same regardless of where it comes from (in the cartel). They have their own auditing and other requirements that make sure of it. And for the end user of a site it (should be) of no concern which CA is behind the cert. Just what level of validation is the cert. And how many users actually care? Not many (except for the branded "green bar"). -- Ville signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Enigmail speed geeking
On 12.03.15 20:52, Robert J. Hansen wrote: >> My point was that you wrote multiple paragraphs worth of stories on >> > two emails from which I really got the impression that people should >> > just not bother. > In response to someone who was thinking that storing keys on your hard > drive was categorically unsafe, and that smart cards were categorically > necessary, yes. Absolutely. I agree. I think the difference of opinion here stems from how I read the reply you sent. After the first couple sentences it's not much about answering the question anymore :). The questions was: Are smart cards a must? No they are not. >>> The answer is, "it depends." >> >> Isn't "it depends" exactly what I said ? > > No. You said they add security, period, and that they either > inconvenience minutely or add convenience. All things being equal, they do practically add security, period :). Well, you're quite right that it's impossible to say that they would add security in all situations. Maybe they could also weaken it in some. But you can use the same passphrase with or without the card. You can have your subkeys on the card or on the computer. Maybe you can fill in the rest. I.e. all things being equal: The card can and on defaults probably will limit the amount of passphrase attempts. And then it locks. Is it absolutely secure against hacking? No. But it should be quite difficult to hack. And an important point if to only have subkeys in there that you can revoke. > That's not an "it depends" > answer. That's a "this is true in all times and situations" answer, and > that's exactly wrong. I said "depending on the user and use case". It is an it depends answer. > They do *not* add security in all times and > situations I'm not making such a claim. The world is not black and white. Yes or no only. I'm not talking about some theoretical, mathematically proven statement that smart cards are more secure in every possible way. They are not. >, and they do *not* only ever cause minute inconvenience. I don't know how you count the 30-45 second number from before but for me it adds 1-10 seconds, maybe. Hard to estimate but it doesn't really add any inconvenience to my use. And obviously, that's quite subjective. I'm not even trying to make a point that they would be more secure all the time. But, practically, they can be a cheap and convenient way to add security. Everyone has to evaluate their use case though. Here's an example. Is it better to store secret keys on each computer or a smart card? I use multiple different computers and think that it's more secure to have the keys on my smart card. So, more security by not having to distribute the secret keys to all those computers. I'd say that's convenient security as the secret keys come with me to whichever computer I happen to be using. -- Ville signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Enigmail speed geeking
On 12.03.15 19:21, Robert J. Hansen wrote: > If you think I'm portraying them as "completely unusable," then I think > you didn't bother to read my message very closely. I read both of your messages quite closely. Had you merely pointed out the downsides of having to carry a card, a reader etc. I would probably have just agreed with you and likely just read and said nothing. My point was that you wrote multiple paragraphs worth of stories on two emails from which I really got the impression that people should just not bother. On 12.03.15 19:55, Stephan Beck wrote: >> Yes, thanks a lot. From your answer I deduce that a single-user, >> non-professional environment may not require use of a smart card, >> or may not require it with the necessity it may have in high-security >> environments. It would appear so did Stephan. >> I think they add security and depending on the user and use case >> they either add inconvenience minutely or the complete opposite, they >> add usability. > > The number of environments, number of users, and number of use cases, is > way too vast to be able to make a glib statement like this. You're just > wrong. > > The answer is, "it depends." > Isn't "it depends" exactly what I said :)? I think you went a bit overboard with the stories and wanted to point that out, that's all. Smart cards are not some scary thing only "necessary" in "high-security environments". Whatever that might mean. -- Ville signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Enigmail speed geeking
> But for just as many users, smart cards are inconvenient and overkill. > Frankly, they have awful usability, just terrible. … > finding the smart card is > easy -- it's in my wallet -- but finding the smart card *reader* is the > sort of thing that leads me to crazed conspiracy theories. That's quite a personal issue to count as a failing of smart cards. That whole rant about the reader being MIA is, /for me personally/, a complete non-issue. I keep it attached to the smart card. > I'm not sure > the (marginal) additional security from using a smart card is worth the > (very real) usability expense. Oh, you mean like being able to use a more humane PIN / passphrase? On 12.03.15 18:25, Robert J. Hansen wrote: > Then I discovered the downside of USB tokens: they don't > take well to going through the wash. Are you serious? I wouldn't know but I'm guessing the computer you use to decrypt those messages won't take too well to water either. Sure you need a reader and sure, you shouldn't throw the reader into water but come on. You go out of your way to make them sound like something completely unusable. I think they add security and depending on the user and use case they either add inconvenience minutely or the complete opposite, they add usability. -- Ville signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Suggestions for a Practical Scheme to Manage Multiple Identities?
On 10.03.15 04:41, NIIBE Yutaka wrote: >> So this is not a question about portable flash drives vs. smartcards per >> > se. I _think_ I understand those risks and trade-offs but if there is >> > something I'm missing then, of course, I'd like to know. > I had an experience that one of my family members took my portable > flash drive for his/her own purpose (and it took hours/days for me to > realize the fact). > > This might be another risk. On top of all the other problems of a general purpose storage device. I'd say just go with a smartcard or purpose built token device [1][2]. As for the multiple identities, different smartcards as needed. That makes the reader the only device to carry and the cards you can cut (some precut) to SIM-card size to make carrying easy. And there are small readers available. [1]: http://www.seeedstudio.com/wiki/index.php?title=FST-01 [2]: http://www.fsij.org/doc-gnuk/ -- Ville signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Thoughts on GnuPG and automation
On 04.03.15 12:48, Werner Koch wrote: >> that doesn't tell you about proprietary projects that have chosen not to >> > use GPGME. I've had clients refuse to use GPGME because of the >> > licensing, even under the LGPLv2.1. (Foolish, I know.) Other times > And I have had several hints that it was used anyway and violating the > license. But that is another story. > > If there is a compelling reason to change the license, like to increase > the adaption of mail encryption, I am willing to consider that. I am > able do that for most of the code but there are some practical > drawbacks, like the ability to share code between the other libraries. > I'd rather not have a license changed off copyleft. -- Ville signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Thoughts on GnuPG and automation
On 04.03.15 18:21, Bjarni Runar Einarsson wrote: > GPGME proponents will be frustrated to hear that this knowledge actually > makes me feel much better about Mailpile's decision to wrap gpg > directly: it means I've removed two layers of abstraction between my > code and gpg! Win! Although supposedly such layers are supposed to help > developers (and people will continue to accuse me of NIH and whatnot), > in my experience on other projects, they've more often than not been > sources of additional architectural constraints and bugs of their own. Separation of concerns. Separating different, sufficiently unrelated, functionality into their own layer / process / service can be just as beneficial as on a normal *NIX using multiple processes to achieve a given task. I.e. the so called "UNIX philosophy" [1]. > OpenSSL wrapper libraries for Python are a prime example, for one. More > code: more bugs. Implementing something in one monolithic binary instead of two or more separate binaries does not necessarily mean much more code. We can always screw up wherever the functionality is. > This is one of the reasons having a native "protocol" such as JSON or > Assuan in the gpg binary itself (or the gpg-agent if things move there) > appeals to me so much. I'm not taking sides one way or the other right now on this one… > With two layers of wrappers, we have to wait for GPGME to get updated > and THEN wait for the Python wrappers to get updated. With separate layers they can be updated separately. There is no need for every single GPG user to update the binary if a change in some layered feature needs to be updated. If features live in a separate layer, certainly there needs to be some coordination and care that a change does not break some dependant layer. But that's not really anything new and one needs to always be careful with such things whether with monolithic and modular binaries alike. > A well defined protocol also > has the potential to eliminate mountains of platform-specific hacks So it has. [1]: https://en.wikipedia.org/wiki/Unix_philosophy -- Ville signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Thoughts on GnuPG and automation
On 04.03.15 01:55, Hans of Guardian wrote: > In Android, you can't really have shared libraries. Apps share functionality > at a higher level (aka Activities and Services). Qt applications can share Qt libraries [1] with an external dependency called Ministro [2]. [1]: http://doc.qt.io/qtcreator/creator-deploying-android.html [2]: https://play.google.com/store/apps/details?id=org.kde.necessitas.ministro -- Ville signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Fwd: Re: German ct magazine postulates death of pgp encryption
On 03.03.15 14:54, Stephan Beck wrote: > as your message hasn't reached the list inspite of being addressed to it It did :). -- Ville signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Please remove MacGPG from gnupg.org due to serious security concerns
On 21 Feb 2015, at 15:55, Xavier Maillard wrote: > > Hi Ville, > > Ville Määttä writes: > >> I happen to use Mail so for a long time I’ve been using the GPGMail >> plugin with a brewed[2] upstream GnuPG. I.e. *just one of the >> things in the GPG Suite*. I’ve talked about this setup before in >> the thread [3]. If one doesn’t use Apple Mail there is no reason to >> use GPGTools at all. > > Thanks for that ! I thought I had to install it. So, I can drop it > and install GPG via brew ? > > Regards > -- > Sent with my mu4e Yes that's right. You can also use the 2.1 installer linked to from gnupg.org downloads. gpg-agent and pinentry-mac can also be installed via brew. For 2.0.27 you can use the write up on this list I linked to. You might need to adapt it a little bit. For 2.1 you shouldn't need the launchd stuff* unless you use SSH. Btw. I noticed there's now a brewed 2.1. Wasn't 2.1.2 yesterday but didn't look at it any more closely yet. * it was mentioned that 2.0.24 already made the agent on-demand changes which make launchd unnecessary (when not using SSH). The scripts don't hurt anyway. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Whishlist for next-gen card
On 20.02.15 15:27, NdK wrote: >>> 5 - possibility to export private keys to user-certified devices >> > That pretty much defeats the point of using a smart card in the first >> > place. > That's not "uncontrolled export", and in fact… > …(snip)… > while importing a key (so that you "can't" alter -actually > it's just "really hard", but doing that should invalidate signatures on > your master key!- the policy by exporting from a device and importing on > another). > There in lies the problem. It's really hard -> it's doable. What is the use case that absolutely needs exportable master keys? -- Ville signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Please remove MacGPG from gnupg.org due to serious security concerns
On 20.02.15 16:44, Lukas Pitschl wrote: > Pinentry-mac is one project we’ve „revived“ and thus only added stuff on top > of the old code instead of refactoring it. > We’ve been planning to do that for a long time now though, so we’ll > definitely look into that and check out how other UIs do it, like GTK. And it might make sense to start clean with the premise of it being a front end like the others. -- Ville signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Please remove MacGPG from gnupg.org due to serious security concerns
On 20.02.15 11:36, Lukas Pitschl wrote: >> No pinentry, nothing just happens. /Will need to >> > troubleshoot this further on 2.1.2 to try to find out more./ > We’ve noticed that the hang occurs in pcsc_get_status_change. Instead of > receiving a timeout, it simply hangs forever, due to a bug in Yosemite’s PCSC > implementation. And it happened again when sending one of the replies. Sending of email and gpg 2.1 process hanging around waiting for something. Killed /scdaemon/, sending of email failed with error, and on retry pinentry popped up and everything worked again. -- Ville signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Please remove MacGPG from gnupg.org due to serious security concerns
On 20.02.15 11:29, Lukas Pitschl wrote: > It would be great if there’s an outline of the changes which might break > backwards compatibility (if any). From usage point of view: https://gnupg.org/faq/whats-new-in-2.1.html >> The things that would require a little changing are the launchd >> templates that are used to start gpg-agent et al. I've been using my own >> templates already before and with 2.1 it's even simpler as per the >> changes to related gpg-agent. This sort of a script is not even >> necessary unless one needs SSH support which I do. I've attached my new >> template here. >> > > Since gpg-agent was changed to be started on demand we’ve not been using any > launchd scripts, as there no longer seems to be a need for them. > Well sure you do, with 2.0.* branch? At leasts the templates are being installed by the suite installer. The on-demand change is with 2.1. > since all the communication goes through our Libmacgpg framework. What is the need for Libmacgpg and its dependencies to MacGPG? I.e. why don't the tools just directly communicate with gpg-agent et al.? (Not including basic abstraction of functionality.) > One that was recently mentioned on our support platform is that pinentry > doesn’t store pass phrases if used with homebrew’s gnupg, it does however if > they’re using MacGPG2 Hmm, why would pinentry cache anything? I might be quite wrong but shouldn't gpg-agent be responsible for this? -- Ville signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Please remove MacGPG from gnupg.org due to serious security concerns
On 20.02.15 12:42, Jonathan Schleifer wrote: > Might I suggest that you start with pinentry? Agreed. > It would be really helpful if you could instead create a new subdirectory > cocoa and do it like the other pinentries. Oh yes, definitely agreed. Integrate the necessary changes to the upstream build of pinentry as just one more front end option. -- Ville signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Please remove MacGPG from gnupg.org due to serious security concerns
On 19.02.15 21:18, Ville Määttä wrote: > Surely someone from the KDE / larger community > using pinentry-qt4 has been working on a QT 5 version of pinentry? Ok, found it :). Issue #1806 [1]. [1]: https://bugs.g10code.com/gnupg/issue1806 -- Ville signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Please remove MacGPG from gnupg.org due to serious security concerns
On 18.02.15 13:05, Jonathan Schleifer wrote: >> > Upstream still does have the issue which now seems to have been fixed in >> > the fork but in a binary removed from upstream… > I really can not confirm this. I am running vanilla GnuPG 2.1.2 (built from > source) on Yosemite (10.10.2 to be exact) with a Gnuk without any problems. Previously I was running brewed 2.0.26. And now I've experienced the similar issue with a speedo build of 2.1.2. There's still definately something going awry but I'll need to do some more testing to find out more. I'm using the FSFE card and the issue is a hang when it should be asking for PIN. > I suppose it might be a good idea to have a Qt GUI. I kinda had that in mind :). QT 4 is going out of support very soon, i.e. sometime this year. Surely someone from the KDE / larger community using pinentry-qt4 has been working on a QT 5 version of pinentry? -- Ville signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Please remove MacGPG from gnupg.org due to serious security concerns
On 18.02.15 07:21, Werner Koch wrote: >> wrappers or fixes upstream. Case in point: Has the fix for gpg-agent / >> > scdaemon hang been discussed upstream at all [4], [5]? In MacGPG there >> > is still ../libexec/gnupg-pcsc-wrapper which has been modified in >> > commit f4c3e1bb to fix the issues of scdaemon hanging in Yosemite >> > [6]. GnuPG proper has removed it in bc6b45 [7]. How would one go about > I just tried to figure out what this is about. The problem description > is pretty clear but I can't easliy find a description of the solution. > I don't think this has been discussed upstream. > > Right, in 2.1 there is no more need for the pcsc-wrapper because we > switched from Pth to native threads (wrapped by the ntph library). > Yep, unfortunately it would appear the same or identical issue does occur with a speedo build of 2.1.2. The issue is essentially that smartcard works for the first time but once some-indeterminate-time has passed, gpg just hangs. No pinentry, nothing just happens. /Will need to troubleshoot this further on 2.1.2 to try to find out more./ >> fixing this issue for upstream? Has GPGTools contributed anything >> regarding this other than the initial discussion[8] about the issue? > > There was no followup on my answer. As we all now mailing lists are a > primary source to evaluate problems and thus it is usually a good idea > to post the found or not-found solution. I think we might want to move some of this discussion to gnupg-devel side at some point. -- Ville signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Please remove MacGPG from gnupg.org due to serious security concerns
On 18.02.15 07:21, Werner Koch wrote: >> > command line tools. *I think there is no more reason to develop >> > MacGPG*, i.e. a port, anymore. Let the port die. > Can you briefly explain how Patrick's new installer [1] is related to that? > Would it be an option to use that as the core for gpgtools? > > [1] https://sourceforge.net/p/gpgosx/docu/Download/ > I haven't tried Patrick's installer but it should be a fine option as the core. The Mail plug-in should work just fine with 2.1 like it works with upstream 2.0.* builds. I'm not aware of any specific need for MacGPG in that regard. Same goes for the other little helpers. The things that would require a little changing are the launchd templates that are used to start gpg-agent et al. I've been using my own templates already before and with 2.1 it's even simpler as per the changes to related gpg-agent. This sort of a script is not even necessary unless one needs SSH support which I do. I've attached my new template here. I know, that's a lot of /shoulds/ :). There is an existing ticket [1] for MacGPG upgrade to 2.1 and it links to a couple of their support request [2] [3], one of them mentions the need to /"first have to adapt our library which is responsible for communicating with the gnupg binary"/. Lukas, maybe you could comment on the other tools' dependencies with MacGPG, if any. [1]: https://gpgtools.lighthouseapp.com/projects/66001/tickets/142-update-to-gnupg-21 [2]: https://gpgtools.tenderapp.com/discussions/problems/29108-gnupg-21-ecc-is-now-in-stable [3]: https://gpgtools.tenderapp.com/discussions/suggestions/150-gnupg-21-modern-for-mac -- Ville http://www.apple.com/DTDs/PropertyList-1.0.dtd";> Label com.ruriat.gpgagent ProgramArguments /usr/local/gpg21/bin/gpgconf --launch gpg-agent RunAtLoad StandardErrorPath /dev/null StandardOutPath /dev/null ServiceDescription Run gpg-agent at login. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Please remove MacGPG from gnupg.org due to serious security concerns
On 17.02.15 23:32, Lukas Pitschl wrote: > The best way to reach us is either our support platform at > https://gpgtools.tenderapp.com or t...@gpgtools.org. Ok, that link explains the certificate and it makes more sense. I can see you've already changed at least the first link to the support site on the front page. Great. -- Ville signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: 2.1.2: keyserver route failure
> On 18 Feb 2015, at 19:07, Johan Wevers wrote: > > Admit it, IPv6 has > failed. It may get some uses, but the widespread adaptation of carrier > NAT has made it largely obsolete. Utter, complete, nonsense. -- Ville ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: 2.1.2: keyserver route failure
> On 18 Feb 2015, at 21:13, Daniel Kahn Gillmor wrote: > > I'm not convinced that it's gnupg's job to compensate for > unreasonably-configured IPv6 stacks that think they have a route but > actually don’t. I agree. I think the actual problem should be addressed at the networking level instead of adding logic to GnuPG. -- Ville ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Please remove MacGPG from gnupg.org due to serious security concerns
> On 17 Feb 2015, at 21:16, Juergen Fenn wrote: > > as you've pointed > out, the GPGTools have decided to go all commercial including, I > didn't realise this before, a closed code repository so that no one > can study the code? Is this true? I can't believe it. That’s not quite true. They must release the changes they make. The private repository issue has been corrected and at this time one should be able to build the whole suite on their own. -- Ville ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Please remove MacGPG from gnupg.org due to serious security concerns
> On 17 Feb 2015, at 21:03, Sandeep Murthy wrote: > > As a user, not a developer on MacGPG, the issues previously > raised here about the remote execution of scripts etc. may be > questionable, but they do not directly affect my use of the software, > which is nothing but a front end for GnuPG. If MacGPG were not a fork that would be the situation. Alas, it *is a fork and not just a front-end* for GPG. There are binary level differences from upstream which the average user does not know, nor should they need to. > The GPG plug-in for Apple Mail is not without its shortcomings but > it is incredibly easy to use and works well the other components > of the GPG suite. I have not used Enigmail, but it’s simply a > question of choice. I agree. I wouldn’t like anything better than to have all users using an open source client but I don’t have any illusions of getting there any time soon. Thus, plugins for the system default are necessary. -- Ville ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Please remove MacGPG from gnupg.org due to serious security concerns
> On 17 Feb 2015, at 18:31, Martin Paljak wrote: > > Not sure about overall GnuPG affection with Apple or other closed > source software, but the PC/SC layer in Yosemite is broken (again): > > http://ludovicrousseau.blogspot.fr/2014/12/os-x-yosemite-and-smart-cards-known-bugs.html Yeah, Apple has once again moved things around and even seemingly reimplemented some things for no apparent reason. Hard to know why because Apple doesn’t talk much about their plans with the outside world. Ludovic has been doing a great job of finding and reporting issues to Apple. > …for the not-so-powerusers > on a not-so-great platform. It is the users's choice to use OSX (not > Linux), the same way it is their choice to use Mail.app (not Enigmail) > the same way it is their choice to use a simple to use binary > installer with crappy build machinery instead of verifying the > checksums of every download. You’re letting your hate shine bright. Haters gonna hate. >> Another: GPGTools support site has a certificate mismatch [14]. WTF is a >> *.tenderapp.com cert doing here? > > Because that site is run by Tender and if you connect to the https > version, you get their site? Probably makes sense to bug Tender with > this. GPGTools is very much responsible for where their site is hosted and the proper use of such things as certificates. In the scheme of things the actual hosting issue is probably quite small but one could say that *GPGTools has not planned for the use of HTTPS on their support site at all*. > So, generally speaking: if the upstream has not catered to the OSX > folks and somebody on the internet has, I would not blame GPGTools > guys for doing it. That makes no sense. > Yes, it would be nice if one at least tried to > contribute back to upstream and to work in an open manner, but at > least they DO something, for what there is apparent need. Nothing requires GPGTools to contribute their code changes back upstream but licensing does require the source to be available. There was a period when this licence requirement was not adhered to. Fortunately, as I said, it was momentary and at the moment as far as I know they have merged back to the public repository. -- Ville ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Please remove MacGPG from gnupg.org due to serious security concerns
I’ve had some concerns about GPGTools for months now. For some time I've disliked the way the project is being run, the communication of what they are planning and the way they have been doing their development for example. Months went by when their Yosemite betas were not available in source at all and development was happening in a separate repository closed from the public [1]. GPGTools makes an installer, GPG Suite, which provides the following: - GPGMail (plugin for Apple Mail) - GPG Keychain (GUI tool for generating and managing keys) - GPGServices (OS X Services menu tools for OpenPGP actions) - GPGPreferences (OS X preferences GUI for some options (gpg.conf) - MacGPG2 (Fork of GnuPG 2.0.26) I happen to use Mail so for a long time I’ve been using the GPGMail plugin with a brewed[2] upstream GnuPG. I.e. *just one of the things in the GPG Suite*. I’ve talked about this setup before in the thread [3]. If one doesn’t use Apple Mail there is no reason to use GPGTools at all. I’ve been planning on writing a request to http://support.gpgtools.org for downsizing / pivoting the project. I just haven’t gotten around to it yet. MacGPG: Years back there was no easy way of getting upstream GnuPG working on a Mac. As I recall there were a couple of ports making a working Mac version and MacGPG was / evolved from one of them. Today the situation is very much different. Anyone can easily install either 1.x or 2.0.x via brew or another preferred method of installing their command line tools. *I think there is no more reason to develop MacGPG*, i.e. a port, anymore. Let the port die. Instead they should use upstream and contribute the minimal amount of wrappers or fixes upstream. Case in point: Has the fix for gpg-agent / scdaemon hang been discussed upstream at all [4], [5]? In MacGPG there is still ../libexec/gnupg-pcsc-wrapper which has been modified in commit f4c3e1bb to fix the issues of scdaemon hanging in Yosemite [6]. GnuPG proper has removed it in bc6b45 [7]. How would one go about fixing this issue for upstream? Has GPGTools contributed anything regarding this other than the initial discussion[8] about the issue? Upstream still does have the issue which now seems to have been fixed in the fork but in a binary removed from upstream… Many times when a new version of OS X comes out GPGTools has been a little late in getting a compatible version out. GPGTools are planning to move to a paid release of GPG Suite [9]. Whether it’s paid or not, my suggestion for GPGTools is to drop MacGPG and start using an upstream version in the Suite. There are a lot of users out there that will not fiddle with command lines, brew or otherwise. And for them there needs to be a GUI package. Quoting from GPGTools support regarding paid support [10], "non-power-users that were partially even surprised, that email does not imply webmail”. "I hope you are aware of the social responsibility that comes with running the official website for gpg on OS X.”. So, *"official website for gpg on OS X"* according to this user critical of making discontinuation of a free version. There is a real problem here in that whatever GPGTools does, affects a large population of Mac users as the "official GPG on Mac”. There is a history of problems regarding GPGTools and MacGPG. This is not the first time that project or decisions of its developers has been questioned [11]. Here’s one: 1. Modify source code to allow non-sensical 8192 bit keys [12]. 2. Have users wonder, at gnupg-users, years later why things don’t quite seem right [13]. Another: GPGTools support site has a certificate mismatch [14]. WTF is a *.tenderapp.com cert doing here? GnuPG provides a GUI for Windows in addition to the set of command line tools. On *NIX official builds are command line only. I think the GUI tooling of not only Mac but other *NIX systems to be quite an important factor in getting wider use for encryption. Such tools must be from a respectable source and properly implemented just as much as the underlying engine. I would argue GnuPG should take the responsibility of such tooling where there isn’t a good option. Other *NIX systems are doing fairly well already so I suppose a Mac GUI would really be the urgent one. And I’m willing to put my time and effort where my mouth is. I would be happy to participate such a project. Links: [1]: http://support.gpgtools.org/discussions/problems/24976-how-to-build-yosemite-branch [2]: http://brew.sh [3]: http://lists.gnupg.org/pipermail/gnupg-users/2014-August/050677.html [4]: http://support.gpgtools.org/discussions/problems/28634-gpg-agent-stops-working-after-osx-upgrade-to-yosemite [5]: https://gpgtools.lighthouseapp.com/projects/66001/tickets/140-gpg-agent-stops-working-after-osx-upgrade-to-yosemite [6]: https://github.com/GPGTools/MacGPG2/commit/f4c3e1bbf1c96cf03ad33a364ec10365f68bf63f [7]: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=bc6b452129178
Re: MIME or inline signature ?
> On 13 Feb 2015, at 08:25, Christopher W. Richardson > wrote: > > FWIW, Mac Mail marked this message as spam. Not sure if it universally does > that for all inline sigs, but ... FYI. > > Chris Fortunately it certainly does not. -- Ville signature.asc Description: Message signed with OpenPGP using GPGMail ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Encryption on Mailing lists sensless?
UX-designer-aproach to car design: "We need to remove break and clutch pedals from cars because our user studies say that a 3 pedal interface for driving an automobile is just way too difficult." I say those who can’t be arsed to learn how, do not deserve a driver’s license. You let a child fail and try again until they learn… so on and so forth. Some encryption software UI is too difficult, yes, some pretty much lack a UI. Fair enough. But the "one click is one click too many” defeatist mentality is just wrong. It is not always the UI’s fault and sometimes you just have to say “make the user learn or make ‘em go away”. Yes, it’s a valid option. PS: I work with UI and UX folks on software all the time. Yes, it might get a little heated sometimes :). -- Ville On 18 Nov 2014, at 11:43, Nan wrote: > In an ideal world, yes. But after 20 years of recommending user-to-user > encryption, it's clear most users can't or won't. As Bruce Schneier says, "If > there's anything PGP has taught us, it's that one click is one click too > many." Experts can still encrypt any messages they want individually. We > can't leave the rest of us unprotected. signature.asc Description: Message signed with OpenPGP using GPGMail ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [Announce] GnuPG 2.1.0 "modern" released
No worries on my part. > it seems to install software in versioned directories. Exactly, under /usr/local… and without messing with the system installed binaries or libraries. Some things, like openssl libraries, it will not link automatically to avoid some issues with system provided libraries, but most things are then symlinked to the usual places to provide the brew installed binaries, etc. > I guess it is missing a dependency tracker and > thus when installing Libgcrypt an older (but sufficient) version of > libgpg-error gets installed alongside. It actually tracks dependencies very well… for anything installed and built with Homebrew. It’s a bit like speedo.mk for everything, or the missing apt-get for Mac, some things are “bottled” binaries, some things it’ll build for you, in any case pulling any dependencies as needed. In this case when trying to build a tarred source brew is not in the picture at all and all dependency handling is manual / left for the source configure scripts. And things don’t quite work although the configure script gives an OK on the pre-make checklist. I really have no rush with this. Just debugging for others and happily using the stable branch. I can dig into this myself at some point. It’s also possible whoever is maintaining the homebrew repo for gnupg might solve the issue and push an update there. -- Ville On 11 Nov 2014, at 21:04, Werner Koch wrote: > On Tue, 11 Nov 2014 15:59, mailing-li...@asatiifm.net said: > >> I don’t have CFLAGS set to anything. Mac OS X 10.9 and using homebrew >> for most things. The only thing I do is run ./configure && make in the >> untarred gnupg-2.1.0. I wouldn’t be surprised if there’s something > > I don't know any details about homebrew but it seems to install software > in versioned directories. I guess it is missing a dependency tracker and > thus when installing Libgcrypt an older (but sufficient) version of > libgpg-error gets installed alongside. GnuPG does not pick up that one > but a different installation of libgpg-error and thus you run into these > problems. > > May some someone with more OS X experience look at the problem? > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > signature.asc Description: Message signed with OpenPGP using GPGMail ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [Announce] GnuPG 2.1.0 "modern" released
Hi, That’s somehow just the result of running ./configure. Running a fresh (fresh untarred source, no speedo runs) configure reported this for me: … configure: checking for libraries checking for gpg-error-config... /usr/local/bin/gpg-error-config checking for GPG Error - version >= 1.15... yes (1.17) checking for libgcrypt-config... … That’s a homebrew installed /usr/local/Cellar/libgpg-error/1.17. I don’t have CFLAGS set to anything. Mac OS X 10.9 and using homebrew for most things. The only thing I do is run ./configure && make in the untarred gnupg-2.1.0. I wouldn’t be surprised if there’s something special in the system but I’m not consciously doing anything other that the usual make routine. I also just did a fresh run of speedo.mk and in that case got the same error as Nicholas originally reported (“_default_errsource”). -- Ville On 11 Nov 2014, at 11:28, Werner Koch wrote: > Hi, > > On Thu, 6 Nov 2014 15:22, mailing-li...@asatiifm.net said: > >>> gcc -I/usr/local/Cellar/libgcrypt/1.6.2/include > ! >> -I/usr/local/Cellar/libgpg-error/1.13/include >>> -I/usr/local/Cellar/libassuan/2.1.2/include > ! >> -I/usr/local/Cellar/libgpg-error/1.13/include >>> -I/usr/local/Cellar/libksba/1.3.1/include > ! >> -I/usr/local/Cellar/libgpg-error/1.16/include -g -O2 -Wall >>> -Wno-pointer-sign -Wpointer-arith -o t-sexputil t-sexputil.o >>> libcommon.a ../gl/libgnu.a -L/usr/local/Cellar/libgcrypt/1.6.2/lib > ! >> -lgcrypt -L/usr/local/Cellar/libgpg-error/1.13/lib -lgpg-error >>> -L/usr/local/Cellar/libassuan/2.1.2/lib -lassuan > ! >> -L/usr/local/Cellar/libgpg-error/1.13/lib -lgpg-error > ! >> -L/usr/local/Cellar/libgpg-error/1.17/lib -lgpg-error -liconv > > I do not known your build setup, but how did you manage to include 2 > different versions of libgpg-error - something most be broken in your > setup. Custom CFLAGS set? A messed up stow(1) tree? > > > Shalom-Salam, > > Werner > > > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > signature.asc Description: Message signed with OpenPGP using GPGMail ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [Announce] GnuPG 2.1.0 "modern" released
Yeah, OS X. I’m sorry, I’m sure this is drowning to all the discussion on this thread, I didn’t think too much about the subject. I was replying to Nicholas’ reported issues with building on OS X. My aim was to expand on Nicholas’ report with the info that it’s failing with that error yes, but before that it’s failing linking to version 0.13 of libgpg_error whereas I have 0.16 and 0.17 available. As I see it this feels like a ./configure fail on the dependency. -- Ville On 6 Nov 2014, at 18:48, Werner Koch wrote: > On Thu, 6 Nov 2014 15:14, mailing-li...@asatiifm.net said: > >> Undefined symbols for architecture x86_64: >> "_default_errsource", referenced from: > > OS X ? > > Such a problem has already bee posted today. I have no access to OS X > and thus can't help much. > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > signature.asc Description: Message signed with OpenPGP using GPGMail ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [Announce] GnuPG 2.1.0 "modern" released
Ok I did distclean and here’s the results of speedo for me. Again, libgpg-error version 0.13 seems to be on the wish list: ld: warning: ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' CCLD t-convert CCLD t-percent CCLD t-gettime ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' CCLD t-sysutils CCLD t-sexputil CCLD t-session-env ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' Undefined symbols for architecture x86_64: "_default_errsource", referenced from: _parse_ber_header in libcommon.a(libcommon_a-tlv.o) _parse_sexp in libcommon.a(libcommon_a-tlv.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[5]: *** [t-sexputil] Error 1 make[5]: *** Waiting for unfinished jobs CCLD t-openpgp-oid ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' make[4]: *** [all] Error 2 make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 make[1]: *** [/Users/vmaatta/Downloads/gnupg-2.1.0/PLAY/stamps/stamp-gnupg-02-make] Error 2 make: *** [native] Error 2 On 6 Nov 2014, at 16:14, Ville Määttä wrote: > [shell quote] > > gcc -I/usr/local/Cellar/libgcrypt/1.6.2/include > -I/usr/local/Cellar/libgpg-error/1.13/include > -I/usr/local/Cellar/libassuan/2.1.2/include > -I/usr/local/Cellar/libgpg-error/1.13/include > -I/usr/local/Cellar/libksba/1.3.1/include > -I/usr/local/Cellar/libgpg-error/1.16/include -g -O2 -Wall -Wno-pointer-sign > -Wpointer-arith -o t-sexputil t-sexputil.o libcommon.a ../gl/libgnu.a > -L/usr/local/Cellar/libgcrypt/1.6.2/lib -lgcrypt > -L/usr/local/Cellar/libgpg-error/1.13/lib -lgpg-error > -L/usr/local/Cellar/libassuan/2.1.2/lib -lassuan > -L/usr/local/Cellar/libgpg-error/1.13/lib -lgpg-error > -L/usr/local/Cellar/libgpg-error/1.17/lib -lgpg-error -liconv > ld: warning: directory not found for option > '-L/usr/local/Cellar/libgpg-error/1.13/lib' > ld: warning: directory not found for option > '-L/usr/local/Cellar/libgpg-error/1.13/lib' > Undefined symbols for architecture x86_64: > "_default_errsource", referenced from: > _parse_ber_header in libcommon.a(libcommon_a-tlv.o) > _parse_sexp in libcommon.a(libcommon_a-tlv.o) > ld: symbol(s) not found for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > make[3]: *** [t-sexputil] Error 1 > make[2]: *** [all] Error 2 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > > [/shell quote] -- Ville On 6 Nov 2014, at 16:09, Werner Koch wrote: >> Undefined symbols for architecture x86_64: >> >> "_default_errsource", referenced from: > > >> make[5]: *** [t-sexputil] Error 1 > > default_errsource is defined by init.c which is included in libcommon.a > which in turn is part of the objects linked to t-sexputil. Thus there > should be no problems. Someone (but not me) needs to have a look at the > build log. signature.asc Description: Message signed with OpenPGP using GPGMail ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [Announce] GnuPG 2.1.0 "modern" released
Hi, I can’t use speedo.mk as I get "GnuPG has already been build[sic] in-source”. I’m not going to replace 2.0 at this time so I won’t remove it. With just ‘make’ I get an error on linking libgpg-error. I happen to have versions 0.16 and 0.17 but not 0.13 under the referenced path. [shell quote] gcc -I/usr/local/Cellar/libgcrypt/1.6.2/include -I/usr/local/Cellar/libgpg-error/1.13/include -I/usr/local/Cellar/libassuan/2.1.2/include -I/usr/local/Cellar/libgpg-error/1.13/include -I/usr/local/Cellar/libksba/1.3.1/include -I/usr/local/Cellar/libgpg-error/1.16/include -g -O2 -Wall -Wno-pointer-sign -Wpointer-arith -o t-sexputil t-sexputil.o libcommon.a ../gl/libgnu.a -L/usr/local/Cellar/libgcrypt/1.6.2/lib -lgcrypt -L/usr/local/Cellar/libgpg-error/1.13/lib -lgpg-error -L/usr/local/Cellar/libassuan/2.1.2/lib -lassuan -L/usr/local/Cellar/libgpg-error/1.13/lib -lgpg-error -L/usr/local/Cellar/libgpg-error/1.17/lib -lgpg-error -liconv ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' Undefined symbols for architecture x86_64: "_default_errsource", referenced from: _parse_ber_header in libcommon.a(libcommon_a-tlv.o) _parse_sexp in libcommon.a(libcommon_a-tlv.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[3]: *** [t-sexputil] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 [/shell quote] -- Ville On 6 Nov 2014, at 13:18, Nicholas Cole wrote: > Hi Werner, > > Building on OS X using > > make -f build-aux/speedo.mk native INSTALL_DIR=/usr/local > > gets what looks like most of the way and then fails with the error > shown below. Am I the only person experiencing this, or are others > hitting the same problem? > > Best wishes, > > N. > > > > Undefined symbols for architecture x86_64: > > "_default_errsource", referenced from: > > _parse_ber_header in libcommon.a(libcommon_a-tlv.o) > > _parse_sexp in libcommon.a(libcommon_a-tlv.o) > > ld: symbol(s) not found for architecture x86_64 > > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > > make[5]: *** [t-sexputil] Error 1 > > make[5]: *** Waiting for unfinished jobs > > make[4]: *** [all] Error 2 > > make[3]: *** [all-recursive] Error 1 > > make[2]: *** [all] Error 2 > > make[1]: *** > [/Users/nicholas/Downloads/gnupg-2.1.0/PLAY/stamps/stamp-gnupg-02-make] > Error 2 > > make: *** [native] Error 2 > > On Thu, Nov 6, 2014 at 9:01 AM, Werner Koch wrote: >> Hello! >> >> The GnuPG Project is pleased to announce the availability of a >> new release: Version 2.1.0. >> >> The GNU Privacy Guard (GnuPG) is a complete and free implementation of >> the OpenPGP standard as defined by RFC-4880 and better known as PGP. >> >> GnuPG, also known as GPG, allows to encrypt and sign data and >> communication, features a versatile key management system as well as >> access modules for public key directories. GnuPG itself is a command >> line tool with features for easy integration with other applications. >> A wealth of frontend applications and libraries making use of GnuPG >> are available. Since version 2 GnuPG provides support for S/MIME and >> Secure Shell in addition to OpenPGP. >> >> GnuPG is Free Software (meaning that it respects your freedom). It can >> be freely used, modified and distributed under the terms of the GNU >> General Public License. >> >> Three different versions of GnuPG are actively maintained: >> >> - GnuPG "modern" (2.1) is the latest development with a lot of new >> features. This announcement is about the first release of this >> version. >> >> - GnuPG "stable" (2.0) is the current stable version for general use. >> This is what most users are currently using. >> >> - GnuPG "classic" (1.4) is the old standalone version which is most >> suitable for older or embedded platforms. >> >> You may not install "modern" (2.1) and "stable" (2.0) at the same >> time. However, it is possible to install "classic" (1.4) along with >> any of the other versions. >> >> >> What's New in GnuPG-2.1 >> === >> >> - The file "secring.gpg" is not anymore used to store the secret >>keys. Merging of secret keys is now supported. >> >> - All support for PGP-2 keys has been removed for security reasons. >> >> - The standard key generation interface is now much leaner. This >>will help a new user to quickly generate a suitable key. >> >> - Support for Elliptic Curve Cryptography (ECC) is now available. >> >> - Commands to create and sign keys from the command line without any >>extra prompts are now available. >> >> - The Pinentry may now show the new passphrase entry and the >>passphrase confirmation entry in one dialog. >> >> - There is no more need to
Re: Pinentry curses fallback for gpg
Hi John, You could try the following environment variable: export PINENTRY_USER_DATA="USE_CURSES=1” If that’s no good maybe something in following thread helps: http://lists.gnupg.org/pipermail/gnupg-users/2009-June/036583.html -- Ville On 16 Oct 2014, at 23:02, John Lane wrote: > Hello, I am trying to work out a few things with GnuPG that aren't clear > to me after reading the available documentation. I hope it's ok to ask > for some help? > > Here's my first problem: > > I cannot work our how to tell my desktop-less system to use the curses > pinentry program. I can see that is is configurable for gpg-agent.conf > but I see no equivalent for gpg.conf. The only way I have been able to > do this is to re-point a symlink /usr/bin/pinentry to point to > /usr/bin/pinentry-curses instead of /usr/bin/pinentry-gtk. > > I have read the pinentry readme and see the configure options for it. I > have cross checked with how the package is built for Arch Linux, which > is the Linux distribution that I use. The configure options are > > ./configure --prefix=/usr \ >--enable-pinentry-curses \ >--disable-pinentry-gtk \ >--disable-pinentry-qt \ >--enable-pinentry-gtk2 \ >--enable-pinentry-qt4 \ >--enable-fallback-curses > > The installed binaries are like this: > > lrwxrwxrwx 1 root root 14 May 6 2013 /usr/bin/pinentry -> > /usr/bin/pinentry-gtk2 > -rwxr-xr-x 1 root root 48216 May 6 2013 /usr/bin/pinentry-curses > -rwxr-xr-x 1 root root 107384 May 6 2013 /usr/bin/pinentry-gtk-2 > -rwxr-xr-x 1 root root 153064 May 6 2013 /usr/bin/pinentry-qt4 > > It isn't possible to launch the gtk-2 or qt4 versions without the > requisite libraries being installed, so both fail rather than fall back > to the curses version: > > # /usr/bin/pinentry-qt4 > /usr/bin/pinentry-qt4: error while loading shared libraries: > libQtCore.so.4: cannot open shared object file: No such file or directory > > # /usr/bin/pinentry-gtk-2 > /usr/bin/pinentry-gtk-2: error while loading shared libraries: > libgtk-x11-2.0.so.0: cannot open shared object file: No such file or > directory > > The curses version works fine. Now, as far as I understand, the gnupg > binary uses the symlink "/usr/bin/pinentry" and, with the above > configuration that means the gtk2 version. And, if the system doesn't > have that installed then it fails. > > I can obviously change the symlink to point to the curses version but, > if I do, it'll eventually get reset by my distributions package manager. > > As far as I can tell, it's the pinentry package's "make install" that > creates this symlink rather than something distribution-specific. > > So, what is the correct, approved way to get gpg to use the curses > pinentry ? > > Thanks. > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users signature.asc Description: Message signed with OpenPGP using GPGMail ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Smart Card 4096 Key Question
I bought my SCR3500 and SCR335 V2 from Identive / Chipdrive [1]. I had a problem adding VAT number to the order myself but at least they ship (and kindly handled fixing the bill afterwards). Though, they only seem to have an SCT3511 there, not a 3512. [1] http://www.chipdrive.de -- Ville Määttä On 01 Sep 2014, at 17:18, Philip Jackson wrote: > I tried to buy an SCT3512 usb key device from Amazon.de and also from SCM in > Germany. Neither will ship to an address outside Germany' signature.asc Description: Message signed with OpenPGP using GPGMail ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Problems installing 2.0.26 on Mavericks
Hi, If you don’t have a specific reason for compiling yourself I’d look into installing from Homebrew [1] or Macports [2] and possibly then adding GPG Suite [3] without MacGPG component. I happened to run through this myself just a couple weeks ago so I wrote it up on the list [4]. [1] http://brew.sh [2] https://www.macports.org [3] https://gpgtools.org [4] http://lists.gnupg.org/pipermail/gnupg-users/2014-August/050677.html -- Ville Määttä On 01 Sep 2014, at 21:33, Travis Millburn wrote: > I’m running into problems compiling GnuPG on my mac running OS X 10.9.4. signature.asc Description: Message signed with OpenPGP using GPGMail ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: default user and recipient
You'll need to import the other person’s public key as that is what you are encrypting to. If the other person has uploaded their key to a key server you should be able to find it there: gpg --search-key recipi...@example.com If you already know, preferably the long form, key ID you can just use: gpg --recv-keys 6C70228BDC779E9A If their key is not the key server network there are other options (LDAP, DNS etc.) or they could email you their public key. If it’s in a file: gpg --import filename.asc Ok, you’ve got the key imported and then it’s just: gpg -e filename or directly: gpg -r 6C70228BDC779E9A -e filename > I have not uploaded my newly created key information to a keyserver, Is that > a requirement? Nope. That might for example help others find your key and encrypt to that. PS. Remember to replace the ID from those examples. -- Ville On 29 Aug 2014, at 23:05, Herb Burnswell wrote: > Sorry. I found the default-recipient parameter in the ~/.gnupg/gpg.conf > file. However, when I set: > > default-recipient-self > > I receive: > > No such user ID. > > I have not uploaded my newly created key information to a keyserver, Is that > a requirement? > > TIA, > > Herb > > -- Forwarded message -- > From: Herb Burnswell > Date: Fri, Aug 29, 2014 at 12:50 PM > Subject: default user and recipient > To: gnupg-users@gnupg.org > > > All, > > I am new to pgp and would like to understand the minimum flags that I should > be using for my encryption/decryption needs. I just want to encrypt files > for decryption by one other person. We have exchanged public keys. > > I have read in several places that I can run: > > gpg -e filename > > However I receive: > > You did not specify a user ID. (you may use "-r") > > Current recipients: > > Enter the user ID. End with an empty line: > > Questions: > > 1. Can I set default behavior to not have to specify a user ID? > 2. What other flags should be used per best practices? > > Any guidance is greatly appreciated, > > Herb > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users signature.asc Description: Message signed with OpenPGP using GPGMail ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: So on & so forth
I’d actually like to know why the pinentry / pinentry-curses that come from homebrew don’t seem to work at all. I am now using pinentry-mac but I wouldn’t mind getting the normal pinentry working. All I get is "Agent admitted failure to sign using the key.” without any PIN queries. I can see the card is read but it’s not querying for PIN. Pointing gpg-agent to pinentry-mac resolves this for now. -- Ville On 19 Aug 2014, at 22:52, Ludwig Hügelschäfer wrote: > The supplied pinentry is highly integrated in Mac OS X look and feel > and works reliable - no background/foreground issues like the one from > gpg4win. But I assume, thats windows' fault, mostly. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: So on & so forth
Maybe a little off topic, but then again we are talking about keeping gnupg up to date. TL;DR: I think either MacPorts or Homebrew can be used and one or the other is quite necessary. I do most of my work on the command line / Vim, etc. and using either is just as convenient as apt-get / yum etc. in Linux. Current gnupg2 versions as of 20.8.2014: Homebrew: 2.0.26, also 1.4.18 (gnupg) MacPorts: 2.0.25, also 1.4.18 (gnupg) and 1.2.8 (gnupg12) Rudix: none (only 1.4.18) And the rest is way off topic :). I first looked into Mac package managers in 2006 when Fink was the incumbent and MacPorts more of a challenger. It’s been called a successor to Fink, has the unofficial support of Apple and became pretty much the de-facto package manager around that time. I went with MacPorts then and was quite happy for a few years. Then came along Homebrew as the challenger and I’ve been using it for a few years now. I’ll probably give MacPorts a try again on the next new system. They’re both similar and I think either is good. They have differences which might be important case-by-case but nothing worth some of the heated blogs and forums posts there are. - Neither one replaces any system binaries and both are quite easy to get rid off. And they could co-exists if necessary. - Homebrew tries to avoid duplicates of things included in not only OS X, but also anything that available from language-specific package managers like 'pip', ‘gem', ‘clan’. Installs via MacPorts easily pull in stuff that could be provided by the system. This can be good or bad either way. I rarely have any trouble finding what I need from Homebrew but then I also do use virtualenv and pip, RVM and gem etc. depending on the project. - If one is interested in developing / maintaining a port / brew: MacPorts is modeled on BSD Ports and uses SVN. Homebrew formulas are Ruby scripts in Git, usually in Github I suppose. I didn’t know Fink was still going strong. Good for them. I’ve never used Fink and can’t comment but it is the venerable grey beard project in this bunch. This was the first time I heard about Rudix. I don’t know anything of it and don’t really feel the need to find out :). -- Ville On 19 Aug 2014, at 23:54, Doug Barton wrote: > I notice you suggested (home)brew as the source of the gpg2 package. Can you > say a little about the relative value of that project vs. MacPorts, Fink, or > Rudix? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: So on & so forth
I just went through the process of switching to brew provided gpg2. Anyone not
interested in the particular Mac workflow can skip this one.
So, removing GPG Suite, installed gnupg2 via brew, re-installing GPG Suite
without MacGPG2 (i.e. the Mail.app helpers etc.). There is a bit of work
involved in making a launchd script for gpg-agent and getting a working
pinentry-mac but if gpg-agent is not a requirement, one can just go with the
brew version.
Here’s a quick-n-dirty walk-through:
1. Remove GPG Suite using the uninstalled provided with the installer.
2. brew install gnupg2 (installs gpg-agent as a dependency).
3. Install GPG Suite, choose Customize —> Leave out MacGPG2
4. Install pinentry-mac, either binary [1] or source [2]. The pinentry with
brew didn’t work for me. I went for the binary seeing as the build started
requiring a bit too much dependencies I didn’t want to install right now.
Latest binary worked for me.
5. Add pinentry-mac location to gpg-agent.conf, e.g.
/usr/local/MacGPG2/libexec/pinentry-mac.app/Contents/MacOS/pinentry-mac (I just
copied the binary to where MacGPG2 installs it.)
6. Add a ~/Library/LaunchAgents/com.ruriat.gpgagent.plist [3] <— Note that the
name is quite freeform. Customise as needed.
7. Add the usual agent environment variables to bash profile [4].
[1] https://github.com/GPGTools/pinentry-mac/downloads
[2] https://github.com/GPGTools/pinentry-mackk
[3] My example is based on
http://spin.atomicobject.com/2014/02/09/gnupg-openpgp-smartcard/
** START [3] com.ruriat.gpgagent.plist **
http://www.apple.com/DTDs/PropertyList-1.0.dtd";>
Label
com.ruriat.gpgagent
ProgramArguments
/usr/local/bin/gpg-agent
--daemon
--scdaemon-program
/usr/local/Cellar/gnupg2/2.0.26/libexec/scdaemon
--write-env-file
--use-standard-socket
--default-cache-ttl
43200
--enable-ssh-support
--default-cache-ttl-ssh
43200
RunAtLoad
StandardErrorPath
/dev/null
StandardOutPath
/dev/null
ServiceDescription
Run gpg-agent at login.
** END [3] com.ruriat.gpgagent.plist **
[4] START (file ~/.bash_profile)
GPG_TTY=$(tty)
export GPG_TTY
# GPG Agent for SSH support
if [ -f "${HOME}/.gpg-agent-info" ]; then
. "${HOME}/.gpg-agent-info"
export GPG_AGENT_INFO
export SSH_AUTH_SOCK
export SSH_AGENT_PID
fi
[4] END
--
Ville
On 19 Aug 2014, at 22:33, Doug Barton wrote:
> On 8/19/14 11:17 AM, Ville Määttä wrote:
>> 1. The package and gnupg2 version used has not been updated since October
>> 2013 (2013.10.22). If I’m not completely mistaken the version is still
>> 2.0.22.
>
> Yes, that was my biggest concern as well (and you're correct on the version).
>
> Is there a better solution? I'm comfortable on the command line, and wouldn't
> mind compiling my own if there was a suitable step-by-step guide available.
> I've compiled lots of stuff for FreeBSD and Linux, but while I've used Macs
> in the past I'm new to being a Mac "owner."
>
> If "compile your own" is the right answer, I'd also be appreciative of a
> guide for getting gpg-agent running on a Mac. I see the GPG Suite version
> running in the ps list, and I know how to get .app stuff started at login
> time, but I haven't gotten to the part of the manual where it talks about
> autostart for command line stuff yet. :)
>
> Thanks,
>
> Doug
>
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: So on & so forth
Yeah. Ok. Assuming the Mac guys / fork referred to here are GPGTools / MacGPG2 I can see a couple bigger issues there than just patching in support for bigger keys. 1. The package and gnupg2 version used has not been updated since October 2013 (2013.10.22). If I’m not completely mistaken the version is still 2.0.22. As discussed on the list, one of the more important things would be timely updates. [1] 2. They have a default skeleton gpg.conf with incompatible digest algo etc. (as discussed many times on the list). I don’t think they patch an existing gpg.conf but they are meant to be the easy-to-use packaged installer for first-time users use case. [2] [1] https://gpgtools.org [2] https://github.com/GPGTools/MacGPG2/blob/dev/Formula/Patches/gnupg2/options.skel.patch -- Ville On 19 Aug 2014, at 16:48, Robert J. Hansen wrote: >> They've made a fork? I hadn't realised that. Why on earth? > > They emphatically disagree with some of the key size limits. > > To be blunt, it's made me lose a lot of faith in the developers. In the > grand scheme of things, it's hard to find *anything* less significant than > whether someone uses RSA-2048 or RSA-8192. > > > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: So on & so forth
Quite. Who are the "Mac guys" and what did they fork? -- Ville > On 19.8.2014, at 12.14, Nicholas Cole wrote: > >> On Fri, Aug 15, 2014 at 6:54 PM, Richard Outerbridge >> wrote: >> Still waiting for my email address, yet my blackphone is already in >> my hands. Keep up the good work. >> >> I’m not going to bother with 2.1 until the Mac guyz come to their >> senses about not forking the crypto. Could be a long wait. > > > They've made a fork? I hadn't realised that. Why on earth? > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: card reader (was: riseup.net OpenPGP Best Practices article)
I'm using the FSFE card [1] with SCR3500 [2]. Ok yeah sure, that’s a fellowship card but I actually also wanted to point out the SCR3500 which is a nice similar form factor option for a reader. https://www.dropbox.com/s/jbaxi8ulfdz5585/fsfe_with_scr3500.jpg [1] http://fsfe.org/fellowship/card.html [2] http://www.chipdrive.de/index.php/en/smart-card-reader-writer/rfid-nfc-contact-smart-card-reader-writer/kontakt/scr3500-faltbarer-usb-chipkartenleser.htm -- Ville > On 28.6.2014, at 21.33, Nicholas Cole wrote: > >> On Sat, Jun 28, 2014 at 9:18 AM, Werner Koch wrote: >> On Fri, 27 Jun 2014 21:44, ds...@jabberwocky.com said: >> >>> I do admire the Neo form factor though. >> >> The SCT3512 [1] with an OpenPGP card is also quite convenient: >> >> http://werner.eifzilla.de/sct3512.jpg >> >> I have taken off the ID-000 form factor card for the picture. The label >> is also non-standard but easy to apply. I have that reader in daily use >> for about a year now. kernelconcepts distributes pre-punched cards but >> it is also possible to cut an ID-000 out off a regular sized card. >> Price for the reader w/o card is in the 20 Euro range. > > I can't find a UK source for this, but it does look good. > > Speaking of which, is there an alternative source for GnuPG > Smartcards? KernelConcepts is out of stock until August. > > Best wishes, > > N. > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hkps ssl problem
Hi… any other problems with GPG Tools version? I was using the brew -installed gpg first, had some issues with getting it to recognise OpenPGP card, I switched to GPG Tools version and it’s been ok. Now I’m having trouble getting non-card based keys to work with SSH through gpg-agent. I.e. they don’t, I need to run ssh-agent on any terminal session I want to use local keys. I’m thinking whether it’s worth the effort of trying the brew version again on that… PS. The issue I have with gpg-agent has been on the list some years back in some form, but no real solutions… I’m waiting to debug my setup some more first and I’ll send some more info on the list later. -- Ville On 01 May 2014, at 18:24, Fl wrote: > I already have this line in my config file. > Finaly i found the solution : since im running macgogtools its seems that the > gpg bin which is coming within is not working fine. I install the gnupg > binaries and then use its gpg bin and all work fine. > > Fl > > On May 1, 2014, at 3:39 PM, Hans of Guardian > wrote: > >> >> Looks like you need to get this file and point the config to the real path: >> >> keyserver-options ca-cert-file=/pathto/.gnupg/sks-keyservers.netCA.pem >> >> >> .hc >> >> On Apr 29, 2014, at 4:41 AM, labrani wrote: >> >>> Hello >>> >>> I'm having some problem while trying to use an hkps pool server as >>> keyserver. >>> i am using gpg2 client version on a mac os x maverick os. >>> i have download the cacert file from the site and i verify that i have the >>> good one while testing with curl. >>> >>> here is the configuration of my client : >>> >>> keyserver hkps://hkps.pool.sks-keyservers.net >>> keyserver-options ca-cert-file=/pathto/.gnupg/sks-keyservers.netCA.pem >>> keyserver-options no-honor-keyserver-url >>> keyserver-options debug >>> keyserver-options verbose >>> keyserver-options verbose >>> auto-key-locate keyserver >>> fixed-list-mode >>> keyid-format 0xlong >>> verify-options show-uid-validity >>> list-options show-uid-validity >>> default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 >>> ZLIB BZIP2 ZIP Uncompressed >>> personal-digest-preferences SHA512 >>> cert-digest-algo SHA512 >>> no-emit-version >>> >>> >>> >>> >>> and here is the error i have : >>> >>> gpg2 --recv-keys 0xD9B53384 >>> gpg: requesting key 0xD9B53384 from hkps server hkps.pool.sks-keyservers.net >>> gpgkeys: curl version = libcurl/7.30.0 SecureTransport zlib/1.2.5 >>> Host: hkps.pool.sks-keyservers.net >>> Command:GET >>> * Adding handle: conn: 0x1184800 >>> * Adding handle: send: 0 >>> * Adding handle: recv: 0 >>> * Curl_addHandleToPipeline: length: 1 >>> * - Conn 0 (0x1184800) send_pipe: 1, recv_pipe: 0 >>> * About to connect() to hkps.pool.sks-keyservers.net port 443 (#0) >>> * Trying 80.239.156.219... >>> * Connected to hkps.pool.sks-keyservers.net (80.239.156.219) port 443 (#0) >>> * SSL certificate problem: Invalid certificate chain >>> * Closing connection 0 >>> gpgkeys: HTTP fetch error 60: SSL certificate problem: Invalid certificate >>> chain >>> gpg: no valid OpenPGP data found. >>> gpg: Total number processed: 0 >>> >>> >>> thxs for your help >>> >>> ___ >>> Gnupg-users mailing list >>> Gnupg-users@gnupg.org >>> http://lists.gnupg.org/mailman/listinfo/gnupg-users >> > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Access to www.gnupg.org only via TLS
So, when was the last time you were offered a parachute on flight? :), sorry I just had to. I have to say I agree with Doug on StartSSL, I think they’re doing a more of a service to the community by offering affordable certs and the revocation fee is understandable. And reasonable. And sometimes wavered. They did for us the first time when we were adding domains to a wildcard cert, but a bit later this mess of a bug hit and we revoked again, this time they charged the fee. Shit happens. I do also understand the point why revocation shouldn’t cost money. Why it would lead to certs not being revoked and instead new ones being created [1]. It’s a valid point and something StartSSL should, maybe do, think about. Like so often, there is no one easy solution, it’s a matter of compromising and weighing different needs. On the whole I like what StartSSL are doing and I’m not quite ready to stop using their certs based on this affair. [1] http://blogs.fsfe.org/gollo/2014/04/13/what-the-heartbleed-bug-revealed-to-me/ On 30 Apr 2014, at 22:40, Faramir wrote: > Signed PGP part > El 30-04-2014 15:23, Doug Barton escribió: > > On 04/30/2014 01:25 AM, Martin Gollowitzer wrote: > ... > > Yeah, I don't quite see your point. They are providing a very > > valuable service for free, and charge a nominal fee for revoking a > > cert. If you > ... > > Meanwhile, if your response is going to be in the nature of, > > "Everything I want should be given to me free just because I want > > it" please don't bother. > > IMHO, to be able to revoke a compromised certificate should be free, > since when you get a certificate, you have time to think about if you > really need it, and to consider if you can afford it. But if the > certificate is compromised, then you really need it revoked ASAP. It > is like providing free airplane tickets, and then charging for the > parachute. > > Best Regards > > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -- Ville ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: C# .dll availability?
Howdy, Likely something GPGME (http://www.gnupg.org/related_software/gpgme). Signs point to gpgme-sharp, although it seems a bit inactive, someone more knowledgeable correct me if there’s a better option. https://github.com/danm-de/gpgme-sharp http://stackoverflow.com/questions/4156819/using-the-gpgme-library-from-net -- Ville Määttä On 25 Apr 2014, at 01:07, Charles Spitzer wrote: > Greetings > > Is there a GnuPGP project anywhere that does PGP encryption that is usable in > a C# application? I know I can execute commands at a command line to do this, > but that would require the plaintext to reside on disk somewhere and I’d like > to avoid that. I’d also like to avoid having to roll my own, not being sure > that I’d get it right. > > Regards, > Charlie Spitzer > > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
