Re: GnuPG 2.1.3 Fails to Compile OS X

[Werner Koch]

On Thu, 23 Apr 2015 03:39, gni...@fsij.org said:

> In the git repo, we have an entry of po/e...@quot.po in the .gitignore,
> so, I think that it is not maintained in the repo.  When a developer

Right.  It was removed in 2004!

I expect that bug reports for a certain version a done using freshly
untarred and build tarball.  Thus no old stuff will be around.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GnuPG 2.1.3 Fails to Compile OS X

[NIIBE Yutaka]

On 04/23/2015 11:26 AM, Ben McGinnes wrote:
> Cool.  Since 2.1 is on a one month cycle, I might just wait for 2.1.4
> and try again, that'll give me the changes made from 2.1.3 and not
> trying to make a release equivalent tarball from the current repo
> (although if there's a script for that I might do it later today).

In my theory (which might be wrong), the scenario is like this:

  (1) A developer has his own e...@quot.po for his working directory.

  (2) Werner periodically does POT and PO update (usually before the
  release) to the repository.

  (3) A developer pull from the repository.

  (4) When a developer invokes 'make', it tries to update e...@quot.po
  by msgmerge (although we have a special rule in Rules-quot).
  Then, updated e...@quot.po may have fuzzy entries.

If this is correct, I think that following patch fixes the problem.

diff --git a/po/Makefile.in.in b/po/Makefile.in.in
index eb68ea2..4f2849a 100644
--- a/po/Makefile.in.in
+++ b/po/Makefile.in.in
@@ -56,8 +56,7 @@ XGETTEXT_ = @XGETTEXT@
 XGETTEXT_no = @XGETTEXT@
 XGETTEXT_yes = @XGETTEXT_015@
 XGETTEXT = $(XGETTEXT_$(USE_MSGCTXT))
-MSGMERGE = msgmerge --previous
-MSGMERGE_UPDATE = @MSGMERGE@ --previous --update
+MSGMERGE = @MSGMERGE@ --previous
 MSGINIT = msginit
 MSGCONV = msgconv
 MSGFILTER = msgfilter
@@ -192,9 +191,7 @@ $(srcdir)/$(DOMAIN).pot:
 $(POFILES): $(srcdir)/$(DOMAIN).pot
@lang=`echo $@ | sed -e 's,.*/,,' -e 's/\.po$$//'`; \
if test -f "$(srcdir)/$${lang}.po"; then \
- test "$(srcdir)" = . && cdcmd="" || cdcmd="cd $(srcdir) && "; \
- echo "$${cdcmd}$(MSGMERGE_UPDATE) $${lang}.po $(DOMAIN).pot"; \
- cd $(srcdir) && $(MSGMERGE_UPDATE) $${lang}.po $(DOMAIN).pot; \
+ $(MAKE) $${lang}.po-update; \
else \
  $(MAKE) $${lang}.po-create; \
fi
-- 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Yubikey NEO OpenPGP advisory

[Peter Lebbing]

On 22/04/15 21:06, Werner Koch wrote:
> They probably downplay this bug because of the costs to replace all
> affected Yubikeys.

Oh wait... I somewhat assumed the things were field-upgradeable. I
thought you could pick the applications to load on a multi-application
Yubikey. In that case you can just download a new version of the app on
your Yubikey and you're good to go (although it'd lose the keys
currently on there).

If already deployed Yubikeys are not updatable, that changes things in
my eyes. I don't think I'd still use such a device as OpenPGP card.

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Yubikey NEO OpenPGP advisory

[Peter Lebbing]

On 23/04/15 00:22, Jose Castillo wrote:
> in the case of NFC, which is a big use case for the Yubikey

I hadn't considered NFC at all, it's good you brought it up. In fact, if
sniffing reveals the PIN and my threat model includes physically nearby
attackers, I wouldn't use it at all, whether it had PIN or not.

But I suppose it could work if you only use the NFC functionality when
you're in a safe environment such as your own home. It seems a
comfortable way of using your crypto hardware. As long as you only worry
about attackers that are elsewhere.

A similar scenario from real life:

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.

Or, since everything is relative, where an employee of the shop you're
in only needs to tap the payment terminal to your wallet as they
accidentally bumps into you.

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...

> Personally, I think that it’s unsafe to have a PGP key on an old 
> Yubikey that exhibits this vulnerability, which is why I submitted
> it to the list.

I agree. However, I seem to have been under the wrong impression that it
was a matter of a software upgrade, and that we were merely assessing
the risk that something had gone wrong before you did the upgrade.

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GnuPG 2.1.3 Fails to Compile OS X

[Werner Koch]

On Thu, 23 Apr 2015 09:34, gni...@fsij.org said:

> If this is correct, I think that following patch fixes the problem.

I agree that this is could be the cause for the problem.

> diff --git a/po/Makefile.in.in b/po/Makefile.in.in

Changing that Makefile is not a good idea because it is a standard file
from gettext.  gnupg is at gettext 0.17 so let me try to update it to
0.19 and see whether the problem still persists.  IF so me should take
the problem to the gettext developers.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users