[Enigmail] test suite failures when network is flakey

[Daniel Kahn Gillmor]

Hi Enigmail folks--

https://bugs.debian.org/954268 indicates that when the Internet
connection is flakey, enigmail's tests can sometimes fail or timeout in
unreliable ways.

It would be great if we could update the tests so that they could cope
with an unreliable network.

If anyone wants to suggest a simple way to do that, i could take a stab
at writing a patch, but i'm not sure where to begin.

Regards,

 --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] moving buildscripts to python3

[Daniel Kahn Gillmor]

On Sat 2019-11-09 10:51:35 +0100, Patrick Brunschwig wrote:
>> Anyway, feel free to take a look at my py3 branch, and adopt/merge what
>> you like.
>> 
>> I've uploaded something close to it to debian/experimental, so we can
>> see how that turns out.
>
> Thanks Daniel, I'll look into it :-)

fwiw, the package built just fine using these changes on the debian
experimental build daemons, and there is no change to the generated
binaries.

https://buildd.debian.org/status/fetch.php?pkg=enigmail=all=2%3A2.1.3%2Bds1-3%2Bexp1=1573275641=0

--dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] moving buildscripts to python3

[Daniel Kahn Gillmor]

On Fri 2019-11-08 14:04:25 +0100, Patrick Brunschwig wrote:
> My aim is to require a subset of the tools required by Mozilla to build
> Thunderbird - the python scripts in Enigmail were all copied from the
> Mozilla build toolchain, and I never modified any of them. If the
> Mozilla build tools are migrated to python3, then I'll be happy to copy
> them over to Enigmail.

The Mozilla build tools are migrated to python3:

https://bugzilla.mozilla.org/show_bug.cgi?id=1388447

But they have grown and changed quite a bit since you copied them into
enigmail, it looks like.


https://sources.debian.org/src/thunderbird/1:68.2.1-1/python/mozbuild/mozbuild/

JarMaker.py is now jar.py, etc.

copying all of that over to enigmail's source tree seems problematic at
best -- there's no clear maintenance plan, and it's a ton of code.

It looks like there are three specific commands during the build that
invoke any of the python code:

   Makefile:  util/checkFiles.py
  lang/Makefile:  $(PYTHON) ../util/JarMaker.py -j $(DIST) -t . -f flat 
$(BUILD)/lang/jar.mn
ui/content/Makefile:  $(PYTHON) $(DEPTH)/util/Preprocessor.py -I $(INCLUDE) -o 
$@ $<

checkFiles.py and Preprocessor.py appear to be relatively
straightforward to port, just using /usr/bin/2to3-2.7 and doing
straightforward manual cleanup.

But JarMaker.py has a handful of weird things that weren't very
py3-friendly:

 - use of cmp() (see 
https://docs.python.org/3.0/whatsnew/3.0.html#ordering-comparisons)
 
 - TypeError: '>' not supported between instances of 'time.struct_time'
  and 'int'  when doing:

   if (m.group('optOverwrite')
  or (getModTime(realsrc) >
  outHelper.getDestModTime(m.group('output':

anyway, i think i've fixed them on my py3 branch on gitlab:

https://gitlab.com/dkg/enigmail/commits/py3

enigmail now builds ok for me on a dedicated machine, but it is a little
bit strange -- the updated util/Preprocessor.py sometimes leaves a
zero-byte file, rather than a preprocessed file.  I can't figure out
what's causing that, though i note that it is more likely if no
__pycache__ directory is present.

If i work around that by rebuilding when i observe that the output is
the empty file, then the built package ends up looking identical to the
package i built with python2.

I am afraid i don't understand util/Preprocessor.py well, and it appears
to only be used directly to strip out some UI for postbox in a single
file (ui/content/enigmailMessengerOverlay.xul), which doesn't seem like
a great tradeoff to me -- i'd rather have a sleeker and more robust
build system if possible.

Anyway, feel free to take a look at my py3 branch, and adopt/merge what
you like.

I've uploaded something close to it to debian/experimental, so we can
see how that turns out.

  --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] package/tests/keyObj-test.js -- why claim gpg is older than it is?

[Daniel Kahn Gillmor]

On Wed 2019-11-06 22:04:34 +0100, Patrick Brunschwig wrote:

> this test is to ensure that the openpgp.js variant of the source code
> is used, i.e to test the openpgp.js code. I think you should remove
> the complete set of test cases as you don't ship openpgp.js.

Sorry, just to be clear: what do you see as "the complete set of test
cases"?

I plan to remove everything from lines 41-54 inclusive, unless i hear
otherwise from you :)

  --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] package/tests/keyObj-test.js -- why claim gpg is older than it is?

[Daniel Kahn Gillmor]

Hi Patrick--

package/tests/keyObj-test.js is failing on debian CI infrastructure
(https://bugs.debian.org/944216) on the last two assertions (lines 53
and 54):

41EnigmailGpg.agentVersion = "2.2.1";
42Assert.ok(!EnigmailGpg.getGpgFeature("export-specific-uid"));
43  
44let minKey = keyObj.getMinimalPubKey("bob@somewhere.invalid");
45Assert.equal(minKey.exitCode, 0);
46Assert.equal(minKey.keyData.substr(3, 50), 
"NBFub08oBDACmb04i4u8xUV1ADbnbN5l83mpr70OyWVJb5ElIc");
47Assert.ok(minKey.keyData.substr(-50, 50) == 
"1MU0qOC5SusatWeaebL9igZMla4aqtnLyRwLcsKODSTaZXQw==" ||
48  minKey.keyData.substr(-50, 50) == 
"p9TFNKjguUrrGrVnmnmy/YoGTJWuGqrZy8kcC3LCjg0k2mV0M=", "min key matches");
49  
50minKey = keyObj.getMinimalPubKey("does@not.exist");
51Assert.equal(minKey.exitCode, 0);
52  
53Assert.equal(minKey.keyData.substr(0, 50), 
"xsDNBFub08oBDACmb04i4u8xUV1ADbnbN5l83mpr70OyWVJb5E");
54Assert.equal(minKey.keyData.substr(-50, 50), 
"1MU0qOC5SusatWeaebL9igZMla4aqtnLyRwLcsKODSTaZXQw==");
55  })));

Looking into the failure, i see that minKey is indeed a huge blob (see
attachment below for a line-wrapped version of what is emitted).  It
doesn't have the minimization i'd expect to be applied.

But I think this is happening because line 41 appears to deliberately
cripple enigmail's GnuPG interface by making it think it is version
2.2.1.

What is the point of doing this test in this way?  Debian's package
management is explicitly requring gnupg 2.2.8-2 and higher (basically
2.2.9, because of upstream fixes merged into 2.2.28).  So as far as i
can tell this looks like gratuitous breakage.

But if it's testing something important, i'm reluctant to just strip it
in debian.

Can you help me understand what it's for?

What do you think i should do about it?  Would you object to my removing
these two final tests?  or maybe i should remove all the tests starting
at line 41, since this is irrelevant for debian?  I just don't want to
remove a safety check that i don't understand.  and i don't understand
the purpose of these tests.

Regards,

--dkg

PS I've read the git history of package/tests/keyObj-test.js and the
   comments in there don't give me any additional illumination.

LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUdOQkZ1YjA4b0JEQUNtYjA0
aTR1OHhVVjFBRGJuYk41bDgzbXByNzBPeVdWSmI1RWxJY1ZqNmJUTDJnWUo3Cm9BREJhWDlYeDh0
T04weXBFZjhLdG1tWDdoRkozckgzSld4QUE2dC85b0F0RFpFTU1DVTNUd2JXNC9tOFk4ckwKVEFh
NU1FY1BuQjNpajFzLzY1R0tGZkdkc3orM3lBTkw4cmFvY1JzVW5GNkp6d1FBYU1Scnp6S3orSGhX
MHFzOQpRcFZianU3SGlSQVFTa2gxbWdraWEwcFQyRWRKamxSV2xhNEtwaHV1cWZ1OGxlS3FZSWZr
MnZLc0lCYnZONXIyCmI2eXZURUtienZEMCtub1Y1R21vbEZOeEhtMWtLTzhEWEZZVnBnWGJYSktj
QjR2SjZnZy9MN0s4Nm56elVJTzAKaVdnY3pMZUtUMGtwQXJybVFkd3VBbDFRZW9vaEVvL0RtT1Vq
dnYxaDY0S2NWNUY3ODg0NFlkQlp1amdUVXRXbwpZcFF3RjBZQXlVZjM4KzhoN2ZLOTA5UnppVkR2
N1J4aDgwOHVCVDl5OWtqVktieFZ4U3A4cmNyUjFsNVo5TE5RCjJSK2w3MVpFekR1VkRxNEdkKzBa
d0pHTVoraG5zajd1STRUWEdVeS9IV3ROV1pEd3R0NTR0WEZCR2lqeUFrZUcKL3cwZzhLb3loa2FN
cnY4QUVRRUFBYlFoVlc1cGRDQlVaWE4wSUR4aGJHbGpaVUJsZUdGdGNHeGxMbWx1ZG1GcwphV1Er
aVFIUkJCTUJDQUE3QWhzREJRc0pDQWNDQmhVS0NRZ0xBZ1FXQWdNQkFoNEJBaGVBRmlFRXJjU1ZN
TXRyCkV5UVMyRllRZnhWb3k0bVg5N29GQWx1YjJrY0NHUUVBQ2drUWZ4Vm95NG1YOTdxbTRBdi9R
cnlqR0dHQmZzbU4KSkhqck8rNkpkSm1OUGNZY3V5c3lIK1hVYnJrYThCa0NzYU5oM1NOeVErU0x4
bTY5cGQyM3VIQUMza1ZSK1pENApua3FFdlZ0d29pbGc4d2dYNjN6RnpqeDZ4Skkxdmd3K2l5dWRo
b2tkaEx2azdLV0dtMlJqeFB0OXRIK08xT05tCkpwYWhtcmZrUXZQV2czUVJqNGlSVXM4Q3NjMko5
THFHK3RlR3hNVjhLT2cxQXY1SUt5QktRRG5tcFhTTFdxNWcKQnE4UGZDSklQKzB4eGZXN3paa3Js
QmFPVHFXczhWSHpqaGxYbmRmb1BHemlFZnRJL2hHQU5zYUJCVVlCeEtXRwpSZEtlbTBPZ0xTenZO
WGlhb1Bnb0hkS1hweUhWMVE3aXVrYkx1N1kzRjU4OUZRaitleW1SUmhtbmdZdG1aUEpNCm0vRzdE
aVh6TC9kRXhWOTVSbE5ObUVkMUMrY0Qwamk1WlJNWmxzcTdmUlA2ZGdPWEhBWXBnUy96cGtKcUgz
dFcKZ29GaXRmblE4UjhIZDYxSFYzZkd2YmxvMFd2SmFNQTkycmVpZGZ1UHFWVEdleWc3UkUyWWJn
SFdvcWczNGNZVApOV2RQUUVudUJvYlRNdXlvV29ZZ0Vta0lQODJLWngrS3ltdktpK3R3MElmbzU4
dUQ3V1owdEJwMFpYTjBMbUp2CllrQnpiMjFsZDJobGNtVXVhVzUyWVd4cFpJa0J6Z1FUQVFnQU9C
WWhCSzNFbFRETGF4TWtFdGhXRUg4VmFNdUoKbC9lNkJRSmJtOVJuQWhzREJRc0pDQWNDQmhVS0NR
Z0xBZ1FXQWdNQkFoNEJBaGVBQUFvSkVIOFZhTXVKbC9lNgo0dW9ML1JQU1AyM2VSTE40Yy8xLzZD
WEdTSjlvampKSG1zZTgyS3NuQWNwRllMNU1uaXY1REdkakJRSFFiOTR1CnJWcmlDTHYzYWY5QTdq
eiszTXN4SjJiUGlUMmNrWjFFeHcxWGtqK2RZNDMwU1UyNlpmaUhkelhseFJ0TXFwK2cKMkxVV21w
UlEvWkt0dDJxNlFxeVMwRTZFUkZhbHgyR1hsVDRsSWRQODdIbEZJUDZZSk9yV3FPTGU2bDNtdG1n
QQpmOS9aY3I5TUcvcTc3b2R6QlhuWGxnazI5bGl0S3hJS1BDazV2dkRodys5NVlLRDIxc2lOTTdC
MzNkTFE1YURmCmFVdC9PbkdpMXlIRWpOV1ErSitZNXZaUjZUZFJVTUtnSE5TSWFVcERuMHUvc0FF
eWlCclhHT0lPL29jdWo3c1IKL1VSRTExZUdydURxVWd2RWVhcDVWYS9IN1BvNkJHZVNuR0Fqc3Ro
eWtrdEJybjJhTGV4aVJXaXJadnhvNi9kOQoxRDFLbExSMklrc2pVYUwzNlVwUjUrYVNEeFE1RWUz
ZUVIUEdhVWMxUFIrQTlCaTdlU1hnNjlpM2s3bHNwVUNPCitQNHY4S3ZSRWdqNCs3em1odzAvMFFx
d0FIcUl3UU9hUEV3V0I0ME9qMml4K0J1RDI2ZndWUExERkt4NVRJd1UKc2JLbDdiUWhWVzVwZENC

[Enigmail] moving buildscripts to python3

[Daniel Kahn Gillmor]

Hi Patrick, all--

We're in the process of getting rid of python2 in debian.  Python2 will
lose upstream support in a couple months.

The enigmail 2.1.3 build tooling still appears to depend on python2.
Have you given any thought to porting it to python3?

Is that something you have any specific opinions about?

 --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Future OpenPGP Support in Thunderbird

[Daniel Kahn Gillmor]

On Tue 2019-10-29 19:25:14 +0100, Werner Koch wrote:
> The problem with all that is that _users demanded_ the ability to
> create large keyblocks, because they went to so many key signing parties
> and liked to include arbitrary data.

yeah, there's always a tension between different players in the
ecosystem, and a piece of infrastructure in in the unenviable position
of having to balance equities here.  There is often no "right" answer.
In those cases, evidence-based reasoning -- what are the downsides (and
how severe are they), who experiences them (and how many people), in
what contexts, etc...  these are the only ways to make the decisions,
and we have to accept that the answers might change over time.  Those of
us who work on infrastructure won't necessarily get it right once and be
done.

>> There's a pretty broad consensus that tools should validate input, and
>> that GnuPG needs to take more serious steps than it has in the past to
>> defend against potentially malicious inputs.
>
> You can't.  Neither can a webbroweser avoid downloading huge images or
> other stuff from stupid web pages.

i think the idea that there's no defense against malicious input is
rather defeatist.  There are plenty of counterexamples, where small
changes to how data is handled have provided significant protections --
changing a RAM+CPU-exhaustion attack into a CPU-exhaustion-only attack,
for example, or changing a quadratic amplification attack into a linear
amplification attack, for example.

These small defenses add up, and we should be encouraging more of them,
rather than dismissing work on input validation as impossible.

all the best,

   --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] jsunit updates and distribution

[Daniel Kahn Gillmor]

On Wed 2019-09-18 12:11:12 +0200, john doe wrote:
> Git history  is paramount, locally you can do what ever you want but
> rebasing/merging on what is already pushed is a no go for me.

What is "pushed" ?  what if it was pushed to a feature branch?  what if
it was sent to the mailing list for a review?  What if upstream's policy
is "the master branch *is* a development branch and may change at any
time, i only promise to avoid rollbacks at specific checkpoints (i.e.,
tags)".

Why should the developer not be able to go back and say "hey, this was a
mistake, i think we should do it differently, i sure am glad i caught
that before we released it"?

> I see two reasons why it would be usefull to be able to verify commit:
> - Issue in tag that can be corrected by 'cherry-pick'ing a commit
> While I can verify the signed tag I can not verify the 'cherry-pick'ed
> commit

If you're doing this, and *all* you rely on is that the commit is
signed, you might well have other problems.

For example, there are some commits which are trivially cherry-pickable,
but they only work (that is, "work" means "do what you want them to do")
because of changed behavior from *other* commits were made earlier in
the series.

If you're not shipping a signed release, and you're
backporting/cherry-picking patches without understanding them, and only
relying on the fact that they came from the author, that is not a great
situation.

Again, it doesn't mean that an author's signature (or a committer's
signature) on the commit isn't useful, just that it doesn't really
perform the kind of verification that i think you're suggesting it does.

> - Merging a local branch with upstream
> The command 'git pull' will do a 'git fetch' followed by 'git merge'

i don't see how signed commits help you here, sorry.

> I guess what I'm trying to say is that if the commit is not signed you
> can't be sure who made the commit.

Right, that's true.  And even if a commit is signed, all you can be sure
is that someone with access to the cryptographic token in question made
the commit, not that it is a sensible commit for you to cherry-pick.

--dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] jsunit updates and distribution

[Daniel Kahn Gillmor]

On Tue 2019-09-17 18:55:53 +0200, john doe wrote:
> Do you mind explaining why you are against signing commits?

I'd like to understand what your proposed use case and value proposition
is for signed commits.

I can justify my call for signed tags -- i want to have cryptographic
provenenance for any software release that i package for debian.  Note
that i want to package a *release* though -- not just some arbitrary
(possibly buggy) stage on the way to a release.

do you believe that branch rebases ("changing history") are acceptable
steps for free software developers to take in pursuit of a cleaner git
history?

Who do you expect to verify the signatures on the signed commits?  when
should they verify them?  what specific tests should they perform on the
signatures (e.g. "monotonically increasing in time", "signature timestamp
matches commit message timestamp", "author is from specific set", "no
existing commits ever disappear", etc)

I'm not saying that signed commits are never warranted -- i'm just not
sure what the specific hope is, and what kinds of attacks you hope to
mitigate, and how that practice applies to jsunit itself, since that's
what's under discussion here.

 --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] jsunit updates and distribution

[Daniel Kahn Gillmor]

Hi Patrick--

Thanks for your prompt fixes, i've just uploaded jsunit 0.2.2-1 to
debian experimental for now.

--dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] jsunit updates and distribution

[Daniel Kahn Gillmor]

Hi Patrick, and other enigmail folks--

I'm trying to sort out enigmail 2.1 for debian with tbird 68.

i note that to properly test the new enigmail, i need a newer version of
jsunit for the testing, so i'd like to ship that in debian too.  at
https://www.enigmail.net/jsunit/ i see that jsunit 0.2.2 is available.

i notice a few things that seem amiss with jsunit distribution.  I've
ordered them from highest priority to lowest priority as i see it -- but
if you can fix any of them, that would be great:

 * The git repo at https://git.code.sf.net/u/pbrunschwig/jsunit/source
   has no tags for anything after jsunit-0.2.0, even though
   https://www.enigmail.net/jsunit/ lists 0.2.1 and 0.2.2.

 * The git tags that i do see don't appear to be signed.  Please sign
   any new tags you create!

 * The git repo at https://git.code.sf.net/u/pbrunschwig/jsunit/source
   has an erroneous tag jsunit-1.1.2 -- maybe you want to clean that up
   with something like (untested, i know this syntax works with
   branches, but i don't know about tags):

   git push origin :jsunit-1.1.2

 * The "file not found" situation below https://www.enigmail.net/jsunit/
   is weird.  Rather than giving a 404 return code, a request for a
   missing URL gives a series of HTTP redirections which culminate in an
   HTTP 200 at https://www.enigmail.net/index.php/en/error-404 (that
   page *says* "Error 404 - Page not Found" in the text, but it's
   actually an HTTP 200 OK response!).

   This confuses debian's automatic upstream retrieval scripts ("uscan")
   when they hunt around for trial signatures.  In particular, uscan
   tests the URL at https://www.enigmail.net/jsunit/jsunit-0.2.2.xpi.asc
   and then thinks that maybe a signature is available, because it
   follows the chain of redirects.

   The easiest way to avoid confusing uscan in the short term is just to
   ship .asc OpenPGP signatures alongside the .xpi bundles.  but fixing
   the overall 404 handler would probably be a good thing at some point
   too.

Thanks for your work on enigmail!

   --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] legacy-display part when Subject is protected shouldn't include other headers

[Daniel Kahn Gillmor]

Hi Enigmail folks--

When I send encrypted e-mail with Enigmail and i choose to protect the
Subject, it inserts a text/rfc822-headers part that i've been calling
"legacy-display" (we used to call it "force-display", but i think that
was a misnomer, since protected-header-aware clients do *not* display
it).

I believe the intent of that part is to render any protected headers to
recipients who use legacy clients that are capable of decryption, but
not capable of parsing the protected headers found directly in the
cryptographic payload itself.

Currently, enigmail puts From, To, Cc, and Subject in that
legacy-display part.

If the point of the part is just to display things that might otherwise
be hidden when viewing the message with a legacy client, i think it is
only appropriate to put the Subject: in there.  Otherwise, the
additional non-protected fields (From:, To:, and Cc:) are redundant with
those seen from outside the message.

I've seen this cause confusion for people who say that they think that
they've received a forwarded message or something like that.  If the
legacy-display part only contained the Subject: line (and that line
differed from the outside subject), then i think it would be clearer to
those users that what they're seeing is the intended subject, rather
than a full-blown forwarded message.

I've proposed this change with a patch on the enigmail-2.0-branch here:

https://gitlab.com/enigmail/enigmail/merge_requests/38

I notice that the master branch no longer emits the legacy-display part;
it was removed in a7784d695d105ba210c77220ffcdc6fa83d25a85, due to the
confusion that it causes, according to the commit message, so this
change doesn't apply to the master branch.

Shipping no legacy-display part at all (as the master branch does) means
that a protected Subject header of an encrypted message will be
completely invisible to a message recipient using a legacy client
capable of decryption but incapable of parsing protected headers.
Pretty much every day i receive messages that would be uninterpretable
if i could not read their Subject: line, so i'm not comfortable
suggesting that drop legacy-display from the stable enigmail 2.0 branch
entirely, but i think the minimization proposed in MR 38 is a good way
to reduce the confusion that motivated their removal on master.

   --dkg




signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Cannot send a message, send button doesn't work

[Daniel Kahn Gillmor]

On Wed 2018-12-05 11:51:11 +0100, Patrick Brunschwig wrote:
> On 05.12.18 11:00, Jerzy Spendel wrote:
>> https://sourceforge.net/p/enigmail/forum/support/thread/0023f36d6d/
>
> I assume that solution I proposed at the bottom of the thread does not
> help ...?

for reference for people following this only via the mailing list
archive, the solution Patrick mentions is the following:

It looks like there is a problem with the pEp engine. The easiest
solution is to go to menu Enigmail/pEp > Preferences and switch to
the "Compatibility" tab. Select the option "Force using S/MIME and
Enigmail"

Regards,

--dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] invisible attachments in Mail sent from AppleMail

[Daniel Kahn Gillmor]

On Fri 2018-11-09 17:15:17 +0100, vv01f wrote:
> We periodically get emails of an organization that loves to use their
> Apple products but otherwise is quite nice to be informed about.

a more compact summary of the structure of the message generated by
Apple Mail is here:

A └┬╴multipart/alternative
B  ├─╴text/plain
C  └┬╴multipart/mixed
D   ├─╴text/html
E   ├─╴application/pdf inline [${attachment1}.pdf]
F   ├─╴text/html
G   ├─╴application/pdf inline [${attachment0}.pdf]
H   └─╴text/html

The message itself is part A, which contains parts B and C.

I've seen this for years from senders using Apple Mail, for all kinds of
attachments, including both application/pdf and image/jpeg

> Just I will miss their attachments when I view email in text-only
> mode.

right, by viewing in text-only mode, you're choosing to view B instead
of C.  But the attchments themselves are both subparts of C, so they get
hidden.  It's possible that if they weren't marked as
Content-Disposition: inline that Thunderbird would show them as an
attachment anyway -- i haven't tested.

> To view them I need to enable at least simplified HTML… and for obvious
> and recently highlighted reasons I refuse to do so by default.

I'd have agreed with other messages in this thread that your question
was off-topic for enigmail, except for this bit.  Users of enigmail have
a stronger reason than users of cleartext mail to prefer the plaintext
view.

So this is a tricky situation.  One approach could be to expect
thunderbird to extract all the 

on the one hand, Apple Mail is clearly generating the message
suboptimally.

its structure should ideally put the pdf files as attachments *outside*
the multipart/alternative view:

J └┬╴multipart/mixed
K  ├┬╴multipart/alternative
L  │├─╴text/plain
M  │└─╴text/html
N  ├─╴application/pdf attachment [${attachment1}.pdf]
O  └─╴application/pdf attachment [${attachment0}.pdf]

That way, choosing a preference between text/plain and text/html results
in selection of L or M, leaving the attachments N and O visible for both
situations.

I don't know whether Apple is willing to consider changing how Mail.app
generates MIME structure, or where that would be reported most clearly.
If someone does report it to them, please reply back here with a pointer
to the bug report (or at least a description of the most effective place
to report such a bug).

Another potential optimization/heuristic would be to ask Thunderbird to
pick out specific kinds of MIME subparts even within a
multipart/alternative variant, and to render them as distinct,
downloadable attachments, regardless of any explicit Content-Disposition
header.  I'm note conivnced that this is a good idea, but you could
probably document such a recommendation for Thunderbird most effectively
here:

   https://bugzilla.mozilla.org/enter_bug.cgi#h=dupes%7CThunderbird

Regards,

--dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Password dialogue always in English

[Daniel Kahn Gillmor]

On Mon 2018-10-29 22:53:44 -0400, Jean-David Beyer wrote:
> On 10/29/2018 11:54 AM, Daniel Kahn Gillmor wrote:
>> So the question is: how far back must it go?  What would the changes
>> look like if we were to write a new enigmail that depended explicitly on
>> GnuPG >= 2.2.10?
>
> It would all quit for my
>
> Red Hat Enterprise Linux Server release 6.10 (Santiago)
> gnupg2-2.0.14-9.el6_10.x86_64
>
> System which is up-to-date as of this weekend. Red Hat support their
> releases for 10 years from original release, and backport security
> fixes, but tend do do no feature changes or "improvements."

GnuPG 2.0.14 was released over 8 years ago.  the entire 2.0.x series reached
end-of-life nearly a year ago.

So maybe RHEL should be the ones responsible for maintaining this
backward-compatibility layer in enigmail then, and Patrick can focus on
making things more usable for people running a modern version of the
underlying tools?

I'm just pointing out that the software developers involved here all
have limited time, and when we ask them to prioritize taking care of
ancient dependencies, we're implicitly asking them to *deprioritize*
other development efforts.

   --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Password dialogue always in English

[Daniel Kahn Gillmor]

On Mon 2018-10-29 14:50:57 +0100, Werner Koch wrote:
> On Sat, 27 Oct 2018 17:42, patr...@enigmail.net said:
>
>> but when I find older versions. You obviously can't fix this by creating
>> a new release ;-). Things like "missing MDC" messages for CAST5.
>
> I see.  I general I think it is better to force the use of a current
> versions and not to support old versions.  OTOH, I know that it is a
> problem on Unix where the dtsribution might still run a (patched) old
> versions and you can't easily detect whether that one is up to date.

at some point, though, it really is useful to require a minimum version.
Enigmail can't be expected to ship an indefinite "portability layer" for
all past versions of GnuPG forever.

So the question is: how far back must it go?  What would the changes
look like if we were to write a new enigmail that depended explicitly on
GnuPG >= 2.2.10?

I've done some of that work for debian stable, where several bugfixes
and minor features will be backported to the heavily-patched version of
2.1.18 that ships there, in order to support modern enigmail.

having a functional test suite in enigmail really helps this process,
fwiw, because you can run it against different versions of GnuPG and see
what breaks.

 --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Enigmail does not detect a failed secret key import

[Daniel Kahn Gillmor]

On Tue 2018-10-09 09:22:13 +0200, Werner Koch wrote:
> On Fri,  5 Oct 2018 17:34, d...@fifthhorseman.net said:
>
>> I ran into this with some older versions of GnuPG (e.g. the
>> heavily-patched GnuPG 2.1.18 in debian stretch) during the enigmail test
>
> Do you happen to know whether this is also the case with current
> upstream or with gpg-agent not being run in --supervised mode (ie. on
> Windows or standard Unix)

I encountered the issue while running the test suite in the stretch
version of GnuPG -- but it does not happen on systems with GnuPG 2.2.10.
I did not try very hard to reproduce it with 2.2.10 either, though.

in the test suite, gpg is being run with a custom home directory -- so
the gpg-agent in question is not using --supervised at all, even though
there are systemd user-services that run with --supervised on the same
system.

>> gpg: error building skey array: No such file or directory
>> gpg: Total number processed: 1
>> gpg:   imported: 1
>> gpg:   secret keys read: 1
>> [GNUPG:] IMPORT_RES 1 0 1 0 0 0 0 0 0 1 0 0 0 0 0
>
> Current versions should emit a 
>
> [GNUPG:] FAILURE 
>
> line which would be worth to check for and display as advanced info.

Since i haven't seen the error with recent versions of GnuPG, i can't
confirm this.  But it sounds like a good thing :)

--dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] jsunit versioning (and issues with jsunit 0.2.0)

[Daniel Kahn Gillmor]

On Wed 2018-10-03 16:59:48 +0200, Patrick Brunschwig wrote:
> Am 3. Oktober 2018 15:13:03 MESZ schrieb Daniel Kahn Gillmor 
> :
>>Just to clarify: jsunit 0.2.0 does not work at all without enigmail
>>installed, and the self-test that it ships with is not expected to run?
>
> That's not what I meant. Jsunit 0.2 requires TB 60 or newer,

do you get any output when trying to run thunderbird with -jsunit
tests/sample-test.js from the jsunit 0.2.0 build tree?  I get no output
to stderr.  should i be looking for logs elsewhere?

> and Enigmail 2.1 (master) requires Jsunit 0.2. Enigmail 2.0 requires
> Jsunit 0.1.6 or 0.1.7.

gotcha, thanks.  i'm assuming that 0.1.7 is git commit
a678d4ea3003106a774fe8d0beea7c2450207dbc -- i don't see a git tag
jsunit-0.1.7, or a released .xpi at https://www.enigmail.net/jsunit/

Thanks for helping me debug this.

  --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] jsunit versioning (and issues with jsunit 0.2.0)

[Daniel Kahn Gillmor]

On Wed 2018-10-03 08:54:35 +0200, Patrick Brunschwig wrote:
> Jsunit 0.2 requires at least TB 60 and Enigmail 2.1 (master). If you
> check the gitlab CI file, you'll see that I only use JSunit 0.2 for
> master, but not for the 2.0-branch.

thanks for the details, Patrick.

Just to clarify: jsunit 0.2.0 does not work at all without enigmail
installed, and the self-test that it ships with is not expected to run?

  --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] jsunit versioning (and issues with jsunit 0.2.0)

[Daniel Kahn Gillmor]

Hi Patrick, all--

I'm trying to maintain jsunit in debian so that we can run the enigmail
test suite, and i notice that Patrick recently released jsunit 0.2.0.

in jsunit 0.1.6 (what i've been using), the tests send their messaging
to stdout for the most part.  when i try to run the same tests under
jsunit 0.2.0, i get nothing sent to stdout at all.  It's not clear to me
that the test suite actually runs at all.

here is an approximation of the script that i use to run the built-in
jsunit sample tests on debian's build systems.  You can run it directly
from the build environment:

-
#!/bin/bash
set -e
workdir="$(mktemp -d)"
mkdir -m 0700 -p "$workdir/jsunit-sample-test.profile/extensions"
printf '%s/' "/usr/share/xul-ext/jsunit" > 
"$workdir/jsunit-sample-test.profile/extensions/jsu...@enigmail.net"
cat > "$workdir/jsunit-sample-test.profile/prefs.js" <"$workdir/jsunit-sample-test.profile/times.json"

/usr/bin/thunderbird -profile "$workdir/jsunit-sample-test.profile" -jsunit 
tests/sample-test.js
-

on jsunit 1.6.2, using thunderbird 60.0, i see many lines of output to
stdout, describing the tests that were run, etc.  (i've appended that
output to the end of this e-mail).

But when i upgrade from 1.6.2 to 0.2.0, i get nothing to stdout at all,
even though i'm using the same script.  (This is all with thunderbird
60.0)


So, questions i have about jsunit (and enigmail):

 * is there something wrong with the above script for setting up a new
   thunderbird profile and running the jsunit internal unit tests?

 * should i expect output to stdout from jsunit 0.2.0?

 * is there a specific version of thunderbird that should correspond to
   specific versions of jsunit that aren't marked in jsunit's
   install.rdf?

 * are there specific versions of jsunit that are needed for testing
   specific versions of enigmail?  if so, where are those versions
   recorded?


Regards,

--dkg



here is the output of the above script, with thunderbird 60.0, and
jsunit 0.1.6:
-

JSUnit: service registered
Starting JS unit tests tests/sample-test.js

** Performing Subtest 1 **
*** Executing sub-test 'tests/subtest1.js' ***
** Performing Synchronous tests **
Succeed: true - true == true - JS frame :: resource://jsunit/jsunit-main.jsm -> 
file:///home/dkg/src/enigmail/jsunit/tests/subtest1.js :: syncTests :: line 30
AssertionError: false == true - JS frame :: resource://jsunit/jsunit-main.jsm 
-> file:///home/dkg/src/enigmail/jsunit/tests/subtest1.js :: syncTests :: line 
31
Succeed: 15 == 15 - JS frame :: resource://jsunit/jsunit-main.jsm -> 
file:///home/dkg/src/enigmail/jsunit/tests/subtest1.js :: syncTests :: line 32
Succeed: file '/home/dkg/src/enigmail/jsunit/tests/sample-test.js' OK - 
resource://jsunit/jsunit-main.jsm -> 
file:///home/dkg/src/enigmail/jsunit/tests/subtest1.js :: syncTests :: line 35
1538505747868   addons.repository   DEBUG   No addons.json found.
1538505747878   addons.xpi-utilsDEBUG   XPI Database saved, setting 
schema version preference to 25
** Performing async tests **
Succeed: true - true == true - JS frame :: resource://jsunit/jsunit-main.jsm -> 
file:///home/dkg/src/enigmail/jsunit/tests/subtest1.js :: asyncTests :: line 17
AssertionError: false - false == true - JS frame :: 
resource://jsunit/jsunit-main.jsm -> 
file:///home/dkg/src/enigmail/jsunit/tests/subtest1.js :: asyncTests :: line 18
Succeed: equal - "3" == 3 - JS frame :: resource://jsunit/jsunit-main.jsm -> 
file:///home/dkg/src/enigmail/jsunit/tests/subtest1.js :: asyncTests :: line 19
Succeed: deepEqual - "3" deepEqual 3 - JS frame :: 
resource://jsunit/jsunit-main.jsm -> 
file:///home/dkg/src/enigmail/jsunit/tests/subtest1.js :: asyncTests :: line 20
AssertionError: strictEqual - "3" === 3 - JS frame :: 
resource://jsunit/jsunit-main.jsm -> 
file:///home/dkg/src/enigmail/jsunit/tests/subtest1.js :: asyncTests :: line 21
AssertionError: file '/home/dkg/src/enigmail/jsunit/invalid/filename.txt' not 
found - resource://jsunit/jsunit-main.jsm -> 
file:///home/dkg/src/enigmail/jsunit/tests/subtest1.js :: asyncTests :: line 24
** Performing Subtest 2 **
*** Executing sub-test 'tests/subtest2.js' ***
** Performing Synchronous tests **
Succeed: true - true == true - JS frame :: resource://jsunit/jsunit-main.jsm -> 
file:///home/dkg/src/enigmail/jsunit/tests/subtest2.js :: syncTests :: line 35
AssertionError: false == true - JS frame :: resource://jsunit/jsunit-main.jsm 
-> file:///home/dkg/src/enigmail/jsunit/tests/subtest2.js :: syncTests :: line 
36
Succeed: 15 == 15 - JS frame :: resource://jsunit/jsunit-main.jsm -> 
file:///home/dkg/src/enigmail/jsunit/tests/subtest2.js :: syncTests :: line 37
Succeed: file '/home/dkg/src/enigmail/jsunit/tests/sample-test.js' OK - 
resource://jsunit/jsunit-main.jsm -> 
file:///home/dkg/src/enigmail/jsunit/tests/subtest2.js :: syncTests :: line 40
** Performing async tests **
Succeed: true - true == true - JS frame :: 

[Enigmail] improving (and testing) Autocrypt key minimization

[Daniel Kahn Gillmor]

I noticed that on the 2.0 branch of enigmail, the Autocrypt OpenPGP
certificate minimization wasn't cleanly matching the expected User IDs.
It also wasn't being tested.

I wrote a brief series of patches that improves certificate minimization
and adds it to the test suite:

   https://gitlab.com/enigmail/enigmail/merge_requests/24

I'll probably adopt those changes in the Debian packaging to make sure
that the replacement of OpenPGP.js with GnuPG is still functional, but
i'd welcome those changes upstream on the 2.0 branch as well.

please let me know if you see any problems with that series!

 --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] intermittent failing subprocess test on debian infrastructure

[Daniel Kahn Gillmor]

On Thu 2018-07-12 18:24:57 -0400, Daniel Kahn Gillmor wrote:
> On Tue 2018-07-10 11:27:17 -0400, Daniel Kahn Gillmor wrote:
>> Enigmail is in Debian unstable as of this morning, and should be on its
>> way back into debian's testing distribuation.
>
> One more piece of followup -- we have an intermittent failure of the
> test suite on debian continuous integration infrastructure:
>
> here are two instances of failure:
>
> https://ci.debian.net/data/autopkgtest/testing/amd64/e/enigmail/587942/log.gz
> https://ci.debian.net/data/autopkgtest/unstable/amd64/e/enigmail/586639/log.gz
>
> I think this is the error:
>
> --
> AssertionError: check error message - 18 == 0 - JS frame :: 
> resource://jsunit/jsunit-main.jsm -> 
> file:///tmp/autopkgtest-lxc.h2tft57_/downtmp/build.L2J/src/ipc/tests/subprocess-test.js
>  :: run_test :: line 194
> minimal scenario with stdin and stdout separately
> JavaScript error: resource://enigmail/subprocess.jsm, line 359: uncaught 
> exception: subprocess.jsm: caught error: 
> message: File closed
> fileName: resource://enigmail/enigmailprocess_worker_unix.js
> lineNumber: 554
> column: undefined
> stack: getPipe@resource://enigmail/enigmailprocess_worker_unix.js:554:19
> write@resource://enigmail/enigmailprocess_worker_common.js:190:18
> onmessage/<@resource://enigmail/enigmailprocess_worker_common.js:230:27
> onmessage@resource://enigmail/enigmailprocess_worker_common.js:229:3
>
> errorCode: 4286185473
> --
>
> I don't really understand what it means, and it doesn't always happen --
> in other runs of test suite, the subprocess works just fine.
>
> Does anyone else see this kind of failure?

You can see the intermittent failures here:

   https://ci.debian.net/packages/e/enigmail/unstable/amd64/

we've had a few more unpredictable failures since i reported it, so it
doesn't seem to be something that goes away on its own.

I'd be happy for pointers or ideas on how to resolve it.

--dkg

___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] failing test suites on debian infrastructure

[Daniel Kahn Gillmor]

On Tue 2018-07-10 11:27:17 -0400, Daniel Kahn Gillmor wrote:
> Enigmail is in Debian unstable as of this morning, and should be on its
> way back into debian's testing distribuation.

One more piece of followup -- we have an intermittent failure of the
test suite on debian continuous integration infrastructure:

here are two instances of failure:

https://ci.debian.net/data/autopkgtest/testing/amd64/e/enigmail/587942/log.gz
https://ci.debian.net/data/autopkgtest/unstable/amd64/e/enigmail/586639/log.gz

I think this is the error:

--
AssertionError: check error message - 18 == 0 - JS frame :: 
resource://jsunit/jsunit-main.jsm -> 
file:///tmp/autopkgtest-lxc.h2tft57_/downtmp/build.L2J/src/ipc/tests/subprocess-test.js
 :: run_test :: line 194
minimal scenario with stdin and stdout separately
JavaScript error: resource://enigmail/subprocess.jsm, line 359: uncaught 
exception: subprocess.jsm: caught error: 
message: File closed
fileName: resource://enigmail/enigmailprocess_worker_unix.js
lineNumber: 554
column: undefined
stack: getPipe@resource://enigmail/enigmailprocess_worker_unix.js:554:19
write@resource://enigmail/enigmailprocess_worker_common.js:190:18
onmessage/<@resource://enigmail/enigmailprocess_worker_common.js:230:27
onmessage@resource://enigmail/enigmailprocess_worker_common.js:229:3

errorCode: 4286185473
--

I don't really understand what it means, and it doesn't always happen --
in other runs of test suite, the subprocess works just fine.

Does anyone else see this kind of failure?

 --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] failing test suites on debian infrastructure

[Daniel Kahn Gillmor]

On Tue 2018-07-03 08:37:46 +0200, Patrick Brunschwig wrote:
> On 02.07.18 20:51, Daniel Kahn Gillmor wrote:
>> If it's NS_ERROR_STORAGE_BUSY, i note that there are several different
>> points where thunderbird appears to just wait 10 seconds and retry when
>> sqlite is complaining that it's busy...
>> 
>>
>> https://codesearch.debian.net/search?q=package%3Athunderbird+NS_ERROR_STORAGE_BUSY
>> 
>> Maybe enigmail should adopt the same workarounds?  they're kind of ugly,
>> but i don't know what else to do.
>> 
>> or, is there some other scenario i should look into?
>
> I will look into it. Probably there is nothing else we can do.

Thanks to help from Patrick, and from some good people on the #debci
channel on irc.oftc.net, we've worked around this issue by ensuring that
opening the Autocrypt sqlite db is retried intermittently (for up to 10
seconds) if it fails.

Patrick also identified several other minor concerns about the test
suite, where it was behaving differently on different platforms, and has
tuned either the code or the test suite to simplify and clarify.

As a result, i can now say that the test suite passes correctly on the
debian infrastructure:

https://ci.debian.net/packages/e/enigmail/

Moreover, it turned out to be relatively simple to remove OpenPGP.js
from the 2.0 branch and still pass the test suite (though it depends on
a very modern version of GnuPG, including patches that are expected to
land upstream in GnuPG 2.2.9), so a re-packaged, OpenPGP.js-free
Enigmail is in Debian unstable as of this morning, and should be on its
way back into debian's testing distribuation.

I'm trying to further clean up the enigmail-2.0-branch, to make it
easier to reason about and hack on.

Part of that cleanup is in these two merge requests for the 2.0 branch:

  https://gitlab.com/enigmail/enigmail/merge_requests/13
  https://gitlab.com/enigmail/enigmail/merge_requests/14

I also recommend a review and removal of all unnecessary python and perl
code in util/:

  https://sourceforge.net/p/enigmail/bugs/880/

I am working on getting the test suite to run on gitlab infrastructure
as well so that we can have replicated results.

   --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] [Robert Luberda] [Pkg-mozext-maintainers] Bug#902253: enigmail: Incorrect Polish translation for "Sign message"

[Daniel Kahn Gillmor]

Hi Enigmail folks--

we got this message from a polish-speaking debian user.

I'm not closely involved in the translation work for enigmail, but it
sounds like (a) Polish needs to be fixed, and (b) it might be worth
sending feedback to whichever translator did the bad change to explain
what went wrong and help them to do better in future contributions.

 --dkg

--- Begin Message ---
Package: enigmail
Version: 2:2.0.7-6
Severity: normal
Tags: l10n

For some reason Polish translation of "Sign message" menu position 
has been (recently?) changed from "Podpisz wiadomość" into "Znak Wiadomość" 
which I don't think any Pole can understand, unless they can restore original
English from this  pseudo-Polish after realizing that English noun "sign" 
can be translated into "znak" (e.g. "a road sign" is "znak drogowy").

Regards,
robert


-- System Information:
Debian Release: buster/sid
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), 
LANGUAGE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages enigmail depends on:
ii  gnupg2.2.8-3
ii  gnupg-agent  2.2.8-3
ii  gnupg2   2.2.8-3
ii  gpg-agent [gnupg-agent]  2.2.8-3
ii  icedove  1:52.8.0-1~deb9u1
ii  thunderbird  1:52.8.0-1

Versions of packages enigmail recommends:
ii  pinentry-gnome3 [pinentry-x11]  1.1.0-1+b1

enigmail suggests no packages.

-- no debconf information

___
Pkg-mozext-maintainers mailing list
pkg-mozext-maintain...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mozext-maintainers--- End Message ---
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Unit Tests: do you run the Enigmail test suite? if so, please respond!

[Daniel Kahn Gillmor]

On Wed 2018-07-04 12:42:33 +0200, Patrick Brunschwig wrote:
> On 03.07.18 21:36, Daniel Kahn Gillmor wrote:
>> Now that we have gitlab set up, would you be interested in getting the
>> gitlab continuous integration set up to run on every commit?
>> 
>> https://gitlab.com/help/ci/quick_start/README.md
>> 
>> Patrick, I am not currently a member of the enigmail project on gitlab,
>> but if you want to give me privileges, i could try to get that set up
>> and working for you so that there is some replicable record of the test
>> suite.  Please let me know if you're interested in that.
>
> I am :-) I added you as admin (hopefully with the right permissions).

Thanks!  I'll take a look at it and see what i can do. :)

 --dkg

___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Unit Tests: do you run the Enigmail test suite? if so, please respond!

[Daniel Kahn Gillmor]

On Tue 2018-07-03 08:34:05 +0200, Patrick Brunschwig wrote:
> On 02.07.18 20:39, Daniel Kahn Gillmor wrote:
>>  * when you run the enigmail unit tests
>
> Regularly before pushing commits (at least every few days).
>
>>  * on what platform(s)
>
> On my current macOS notebook. I also had tested the unit tests on
> Windows a while back, but I didn't retry it in the last months.

Thanks for this reportback, Patrick.  It's definitely useful to know!

Is anyone else running the Enigmail test suite?  Feel free to reply to
me privately if you don't want to speak up on-list (encrypt to
0x0EE5BE979282D80B9F7540F1CCD2ED94D21739E9 if you want it rigorously
confidential).

Please respond with this information within the next week if you can
(even if it's initially just a quick private note that says "i run the
enigmail test suite sometimes, i'll get you more details in a few
days").

I plan to summarize any private responses i get, removing all
identifying details, and i'll post the summary here.

>>  * how do you run the tests specifically?
>
> "make test" on my well-prepared development environment. The steps are
> quite the same as yours, but obviously I won't set up a new profile for
> every run during development.

Now that we have gitlab set up, would you be interested in getting the
gitlab continuous integration set up to run on every commit?

https://gitlab.com/help/ci/quick_start/README.md

Patrick, I am not currently a member of the enigmail project on gitlab,
but if you want to give me privileges, i could try to get that set up
and working for you so that there is some replicable record of the test
suite.  Please let me know if you're interested in that.

--dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] Unit Tests: do you run the Enigmail test suite? if so, please respond!

[Daniel Kahn Gillmor]

hi all--

I was wondering whether people could identify whether they currently run
the enigmail test suite regularly (e.g. on each release, or during
active development or bugfixing).  If you do, could you please speak up,
and identify:

 * when you run the enigmail unit tests
 * on what platform(s)
 * what results you tend to get
 * if the results are published or aggregated somewhere, can you link to them?
 * how do you run the tests specifically?

for example, the following is my own report:


~~~
 * i now run the test suite on every new debian package version of
   enigmail, and i also do so repeatedly when any build dependencies
   change.

 * on debian testing and unstable, on the amd64 platform

 * the test suite always fails in the autocrypt test suite :(  (i'll
   follow up about this separately)

 * https://ci.debian.net/packages/e/enigmail/ points to the latest
   results on debian.

 * i run them in a new debian virtual machine, under a non-privileged
   user account with a clean profile, under Xvfb, using something like
   the following commands to set up the profile and launch the tests:


rm -rf ~/profile ~/enigmail*
apt source enigmail
mkdir -p -m 0700 ~/profile/extensions
printf /usr/share/xul-ext/enigmail/ > 
~/profile/extensions/'{847b3a00-7ab1-11d4-8f02-006008948af5}'
printf /usr/share/xul-ext/jsunit/ > ~/profile/extensions/'jsu...@enigmail.net'
printf 'user_pref("extensions.autoDisableScopes", 14);\n' > ~/profile/prefs.js
cd ~/enigmail-*
./configure --with-tb-path=/usr/bin/thunderbird --with-tb-args="-profile $(echo 
~/profile)"
make check
xvfb-run $(which make) unit
 
~~~


I'm asking about this here because a discussion over on gitlab [0]
suggests that the test suites are behaving differently for different
people, and i'm trying to figure out what's going on.

[0] https://gitlab.com/enigmail/enigmail/merge_requests/6

I'd also like to get an understanding of how frequently and in what sort
of environments the enigmail unit tests are actually being run, to know
what sort of coverage we (as a community) are providing.

Regards,

 --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] failing test suites on debian infrastructure

[Daniel Kahn Gillmor]

I'm trying to improve enigmail's test suite coverage in debian, and i've
had difficulties there. This is an attempt to document the problems i'm
running into, in the hopes that someone on-list here can give me
suggestions for new things to try.

To be clear: i can get the tests to pass cleanly when i build the
package myself and when i run its tests.  But i get different failures
when the tests are run on the debian infrastructure.

These errors are blocking me from contributing effective refactoring
work to enigmail, because i want a clean baseline on standardized/common
infrastructure to be able to be sure my changes don't break anything.


Unit tests hang on debian build daemon (buildd) network
---

if i try to run the test suite during the debian build, it hangs on the
debian build daemons (it does not hang when i build it on my own
builders though).  Compare:

   (with test suite)
   
https://buildd.debian.org/status/fetch.php?pkg=enigmail=all=2%3A2.0.7-3=1529511787=0

   (without test suite)
   
https://buildd.debian.org/status/fetch.php?pkg=enigmail=all=2%3A2.0.7-4=1529524566=0

Specifically, the hang happens when the unit tests start:  

make[2]: Leaving directory '/<>'
make[2]: Entering directory '/<>'
make -C ipc/tests
make[3]: Entering directory '/<>/ipc/tests'
../../util/run-jsunit /usr/bin/perl "/usr/bin/thunderbird" --profile 
/<>/test-profile -jsunit main.js
E: Build killed with signal TERM after 150 minutes of inactivity

I don't know why the test fails in this way on the buildd, but my
current work in debian (as of packaging version 2:2.0.7-4) is to just
skip the tests during build :(  Help welcome!



Sqlite.openConnection() fails on debian continuous integration testing
--

Having given up for now on running the tests during the build, i figured
i would try to get them to run on the installed package -- so i added a
debian autopkgtest suite to run the tests after installation.

you can see the failing reports here:

https://ci.debian.net/packages/e/enigmail/unstable/amd64/

on the latest version, which includes all the bugfixes i've made to the
2.0 branch's test suite, i am stumped by the failure found at [1], as
follows:

 [1] 
https://ci.debian.net/data/autopkgtest/unstable/amd64/e/enigmail/545639/log.gz


[…]
*** Executing sub-test 'autocrypt-test.js' ***
2018-07-02 13:59:32.928 [DEBUG] autocrypt.jsm: getOpenPGPKeyForEmail: could 
not open database [Error: Could not open connection to 
/tmp/autopkgtest-lxc.nogrphwa/downtmp/build.6Ql/src/test-profile/enigmail.sqlite:
 2153971713]
AssertionError: "getOpenPGPKeyForEmail1 error Error: Could not open 
connection to /tmp/autopkgtest-lxc.nogrphwa/downtmp/build.6Ql/src/test-profi == 
1 - JS frame :: resource://jsunit/jsunit-main.jsm -> 
file:///tmp/autopkgtest-lxc.nogrphwa/downtmp/build.6Ql/src/package/tests/autocrypt-test.js
 :: processHeader/< :: line 161


I think this failure is happening in Sqlite.jsm's
Sqlite.openConnection() function [2].

[2] 
https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_code_modules/Sqlite.jsm

As with the errors during the build, I am currently unable to reproduce
this particular error on my own machinery.  On my own autopkgtest
machine, the test suite completes successfully.

The error code 2153971713 is 0x80630001, aka either
PEER_E_IPV6_NOT_INSTALLED (seems unlikely) or it is (more likely)
NS_ERROR_STORAGE_BUSY, which is defined in a very convoluted way here:

  
https://sources.debian.org/src/thunderbird/1:52.8.0-1/mozilla/xpcom/base/ErrorList.h/#L865

If it's NS_ERROR_STORAGE_BUSY, i note that there are several different
points where thunderbird appears to just wait 10 seconds and retry when
sqlite is complaining that it's busy...

   
https://codesearch.debian.net/search?q=package%3Athunderbird+NS_ERROR_STORAGE_BUSY

Maybe enigmail should adopt the same workarounds?  they're kind of ugly,
but i don't know what else to do.

or, is there some other scenario i should look into?

   --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] handling async errors more cleanly

[Daniel Kahn Gillmor]

i've just submitted the following minor changes to autocrypt.jsm to
better handle error cases:

https://gitlab.com/enigmail/enigmail/merge_requests/11

in particular, when asynchronous errors do happen, the function that
hits them typically needs to bail out, rather than pushing through in
spite of the errors, because the subsequent code has side effects that
depend on the first bit.

i want this to be my last run at the test suite on the 2.0 branch, but
there may be more yet to come -- i'll bring general concerns about the
test suite up in a separate thread, though.

thanks for considering this,

 --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] clarifying autocrypt errors

[Daniel Kahn Gillmor]

Hi enigmail folks--

When an error arises in enigmail's autocrypt code, it appears to just
throw "error", but that could be in one of several places.

Th patch here makes error reporting a bit more detailed.


It would be good to have this merged into enigmail-2.0-branch.  I've
requested that here:

  https://gitlab.com/enigmail/enigmail/merge_requests/8


Regards,

--dkg


diff --git a/package/autocrypt.jsm b/package/autocrypt.jsm
index c3c736bb..36283bc8 100644
--- a/package/autocrypt.jsm
+++ b/package/autocrypt.jsm
@@ -70,7 +70,7 @@ var EnigmailAutocrypt = {
 fromAddr = EnigmailFuncs.stripEmail(fromAddr).toLowerCase();
   }
   catch (ex) {
-reject("error");
+reject("processAutocryptHeader error " + ex);
   }
   let foundTypes = {};
   let paramArr = [];
@@ -300,7 +300,7 @@ var EnigmailAutocrypt = {
 },
 function onError(error) {
   EnigmailLog.DEBUG("autocrypt.jsm: getOpenPGPKeyForEmail: could not 
open database\n");
-  reject("error");
+  reject("getOpenPGPKeyForEmail1 error " + error);
 }
   ).then(
 function _f() {
@@ -333,7 +333,7 @@ var EnigmailAutocrypt = {
   ).
   catch((err) => {
 conn.close();
-reject("error");
+reject("getOpenPGPKeyForEmail2 error " + err);
   });
 });
   },

___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] a reproducible enigmail .xpi

[Daniel Kahn Gillmor]

Chris Lamb of the Reproducible Builds project points out that most
enigmail .xpi files contain an artifact based on the filesystem sort
order of the build machine. (https://bugs.debian.org/901611)

This makes it hard to reliably reproduce a bit-identical .xpi from
source.  Reproducible builds are expected of most free software today.

Chris offered a small patch to fix the build for the
enigmail-2.0-branch, which i've posted here:

https://gitlab.com/enigmail/enigmail/merge_requests/7

It would be great to have it merged to enigmail-2.0-branch.

thanks,

   --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] 2.0.5 fails "make check" due to missingMdcError (should be mdcError?)

[Daniel Kahn Gillmor]

On Tue 2018-05-22 08:05:21 +0200, Patrick Brunschwig wrote:
> Releases are created on my build server for better repeat-ability, and I
> may have not run it on the 2.0-branch. I'll have to fix the build script...

I've just submitted a series of fixes to the test suite for 2.0 branch
here:

  https://gitlab.com/enigmail/enigmail/merge_requests/6

having these merged to the 2.0 branch would be great -- having a
functioning test suite as a baseline is important for me to reliably
test the version i'm creating that omits OpenPGP.js.

Regards,

--dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] enigmail, jsunit, and e10s

[Daniel Kahn Gillmor]

Hi Enigmail folks--

i think that modern versions of enigmail should work fine with e10s
("electrolysis") builds of thunderbird.  is that right?

however, i note that jsunit does *not* appear to be e10s ready.  i see
messages like this when running the test suite:

 1528150605904   addons.xpi  DEBUG   Add-on jsu...@enigmail.net blocks 
e10s rollout.


that suggests that the test suite won't itself be run under e10s
builds, or maybe that e10s will be disabled during the test suite.  is
there a plan to move jsunit to support e10s?

  --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] looking for a comprehensive enigmail test suite? [was: Re: avoiding openpgp.js for enigmail in debian]

[Daniel Kahn Gillmor]

Hi Patrick!

On Sat 2018-05-26 18:31:46 +0200, Patrick Brunschwig wrote:
>> It'd be really great if there was a test suite that could exercise all
>> the expected functionality, so i could be sure my changes don't breaking
>> them.  do you have anything like such a suite that i could piggyback on?
>
> Run the unit tests in package. I think that almost everything covered by
> tests, except for the ASM.

OK, I've removed OpenPGP.js from enigmail for testing in the most simple
possible way -- just ripping out the files to see what breaks.  And i've
got a dedicated virtual machine that is running eslint directly from npm
so i can run all the tests.

You can find my edits to the enigmail source on the
"enigmail-2.0-no-openpgp.js" branch at
https://gitlab.com/dkg/enigmail.git

below are the results from running "make test" against this branch.  I
don't see any errors in them except for a few warnings about unused
labels, and some eslint complaints about excessive escaping in some
regular expressions.

fwiw, i see the exact same output when i run "make test" against the
branch "enigmail-2.0-branch", without my changes.

Are there other test suites i can run to actually exercise the parts
where OpenPGP.js is used?  I was hoping that this approach would
highight all the breakage that i need to fix, but i'm not seeing it.

Regards,

  --dkg


0 $ make test
static_analysis/eslint ipc
static_analysis/eslint package

/home/npmuser/src/enigmail/enigmail/package/decryption.jsm
  101:34  warning  Unnecessary escape character: \(  no-useless-escape
  101:36  warning  Unnecessary escape character: \)  no-useless-escape

/home/npmuser/src/enigmail/enigmail/package/files.jsm
  523:47  warning  Unnecessary escape character: \/  no-useless-escape

/home/npmuser/src/enigmail/enigmail/package/keyRing.jsm
  308:38  warning  Unnecessary escape character: \.  no-useless-escape
  308:40  warning  Unnecessary escape character: \[  no-useless-escape

/home/npmuser/src/enigmail/enigmail/package/mime.jsm
  353:27  warning  Unnecessary escape character: \?  no-useless-escape
  387:26  warning  Unnecessary escape character: \?  no-useless-escape

✖ 7 problems (0 errors, 7 warnings)

static_analysis/eslint ui
util/checkFiles.py

 checkXUL() ./ui/content/enigmailImportPhoto.xul
 checkXUL() ./ui/content/enigmailKeySelection.xul
 checkXUL() ./ui/content/exportSettingsWizard.xul
 checkXUL() ./ui/content/pepTrustWords.xul
 checkXUL() ./ui/content/keyDetailsDlg.xul
 checkXUL() ./ui/content/enigmailFilterEditorOverlay.xul
 checkXUL() ./ui/content/enigmailMessengerOverlay.xul
 checkXUL() ./ui/content/enigmailGenericDisplay.xul
 checkXUL() ./ui/content/enigmailRulesEditor.xul
 checkXUL() ./ui/content/pref-pep.xul
 checkXUL() ./ui/content/enigmailAbCardViewOverlay.xul
 checkXUL() ./ui/content/enigmailEditKeyTrustDlg.xul
 checkXUL() ./ui/content/autocryptSetupPasswd.xul
 checkXUL() ./ui/content/enigmailCustToolOverlay.xul
 checkXUL() ./ui/content/enigmailEncryptionDlg.xul
 checkXUL() ./ui/content/enigmailAbContactsPanel.xul
 checkXUL() ./ui/content/enigmailConsole.xul
 checkXUL() ./ui/content/enigmailWrapSelection.xul
 checkXUL() ./ui/content/enigmailMsgComposeOverlay.xul
 checkXUL() ./ui/content/pref-enigmail.xul
 checkXUL() ./ui/content/enigmailMsgPrintOverlay.xul
 checkXUL() ./ui/content/enigmailDispPhoto.xul
 checkXUL() ./ui/content/enigmailKeygen.xul
 checkXUL() ./ui/content/pepHandshake.xul
 checkXUL() ./ui/content/enigmailCardDetails.xul
 checkXUL() ./ui/content/enigmailKeyserverDlg.xul
 checkXUL() ./ui/content/enigmailManageUidDlg.xul
 checkXUL() ./ui/content/enigmailMsgComposeOverlay-sm.xul
 checkXUL() ./ui/content/enigmailCheckLanguage.xul
 checkXUL() ./ui/content/enigmailSetCardPin.xul
 checkXUL() ./ui/content/enigmailSelectRule.xul
 checkXUL() ./ui/content/enigmailSingleRcptSettings.xul
 checkXUL() ./ui/content/enigmailPrivacyOverlay.xul
 checkXUL() ./ui/content/columnOverlay.xul
 checkXUL() ./ui/content/enigmailFilterListOverlay.xul
 checkXUL() ./ui/content/enigmailAddUidDlg.xul
 checkXUL() ./ui/content/enigmailMsgBox.xul
 checkXUL() ./ui/content/editSingleAccount.xul
 checkXUL() ./ui/content/pepPrepHandshake.xul
 checkXUL() ./ui/content/enigmailHelp.xul
 checkXUL() ./ui/content/messengerOverlay-sm.xul
 checkXUL() ./ui/content/enigmailPrefsOverlay.xul
 checkXUL() ./ui/content/enigmailEditKeyExpiryDlg.xul
 checkXUL() ./ui/content/autocryptInitiateBackup.xul
 checkXUL() ./ui/content/accountManagerOverlay.xul
 checkXUL() ./ui/content/messengerOverlay-tbird.xul
 checkXUL() ./ui/content/enigmailSignKeyDlg.xul
 checkXUL() ./ui/content/enigmailKeyManager.xul
 checkXUL() ./ui/content/enigmailKeyImportInfo.xul
 checkXUL() ./ui/content/enigmailAmIdEditOverlay.xul
 checkXUL() ./ui/content/enigmailMsgHdrViewOverlay.xul
 checkXUL() ./ui/content/enigmailSearchKey.xul
 checkXUL() ./ui/content/enigmailEditIdentity.xul
 checkXUL() ./ui/content/am-enigprefs.xul
 checkXUL() ./ui/content/enigmailAdvancedIdentityDlg.xul
 checkXUL() 

Re: [Enigmail] avoiding openpgp.js for enigmail in debian

[Daniel Kahn Gillmor]

On Sun 2018-05-27 14:12:25 -0400, Daniel Kahn Gillmor wrote:
>> Run the unit tests in package. I think that almost everything covered by
>> tests, except for the ASM.
>
> thanks, i'll make sure to run both "check" and "unit".  I note that i
> can't run the "eslint" part of the test suite on the debian build
> daemons, since eslint also hasn't been packaged yet for debian:
>
> https://bugs.debian.org/743404

hm, it appears that the most interesting unit tests themselves can only
be run with eslint, which makes it difficult to properly test enigmail
as intended without npm or node.js.

npm2deb depends eslint shows me a rather large list of gaps in the
node/debian intersection (see below), so i can't even get the test suite
to run at build time on the debian infrastructure.

this makes me pretty sad :(

   --dkg

Dependencies:
NPM   Debian
eslint (4.19.1)   None
├─ ajv (^5.3.0)   node-ajv (5.0.0-1)
├─ babel-code-frame (^6.22.0) node-babel (6.26.0+dfsg-3)
├─ chalk (^2.1.0) node-chalk (2.3.0-1)
├─ concat-stream (^1.6.0) node-concat-stream (1.6.2-1)
├─ cross-spawn (^5.1.0)   node-cross-spawn (5.1.0-1)
├─ debug (^3.1.0) node-debug (3.1.0-2)
├─ doctrine (^2.1.0)  node-doctrine (2.1.0-1)
├─ eslint-scope (^3.7.1)  None
├─ eslint-visitor-keys (^1.0.0)   None
├─ espree (^3.5.4)node-espree (3.5.1+ds-1)
├─ esquery (^1.0.0)   None
├─ esutils (^2.0.2)   node-esutils (2.0.2-1)
├─ file-entry-cache (^2.0.0)  None
├─ functional-red-black-tree (^1.0.1) None
├─ glob (^7.1.2)  node-glob (7.1.2-6)
├─ globals (^11.0.1)  node-globals (11.1.0-1)
├─ ignore (^3.3.3)None
├─ imurmurhash (^0.1.4)   node-imurmurhash (0.1.4-1)
├─ inquirer (^3.0.6)  node-inquirer (3.3.0-2)
├─ is-resolvable (^1.0.0) None
├─ js-yaml (^3.9.1)   node-js-yaml (3.11.0+dfsg-1)
├─ json-stable-stringify-without-jsonify (^1.0.1) None
├─ levn (^0.3.0)  node-levn (0.3.0+dfsg-1)
├─ lodash (^4.17.4)   node-lodash (4.17.4+dfsg-1)
├─ minimatch (^3.0.2) node-minimatch (3.0.4-3)
├─ mkdirp (^0.5.1)node-mkdirp (0.5.1-1)
├─ natural-compare (^1.4.0)   None
├─ optionator (^0.8.2)node-optionator (0.8.2+dfsg-1)
├─ path-is-inside (^1.0.2)node-path-is-inside (1.0.2-1)
├─ pluralize (^7.0.0) None
├─ progress (^2.0.0)  node-progress (1.1.8-1)
├─ regexpp (^1.0.1)   None
├─ require-uncached (^1.0.3)  None
├─ semver (^5.3.0)node-semver (5.3.0-1)
├─ strip-ansi (^4.0.0)node-strip-ansi (4.0.0-1)
├─ strip-json-comments (~2.0.1)   node-strip-json-comments 
(2.0.1-1)
├─ table (4.0.2)  None
└─ text-table (~0.2.0)node-text-table (0.2.0-2)

Build dependencies:
NPM   Debian
babel-polyfill (^6.23.0)  node-babel (6.26.0+dfsg-3)
babel-preset-es2015 (^6.24.1) node-babel (6.26.0+dfsg-3)
babelify (^7.3.0) None
beefy (^2.1.8)None
brfs (1.4.3)  node-brfs (1.4.4-1)
browserify (^14.4.0)  None
chai (^4.0.1) node-chai (4.1.2+dfsg-1)
cheerio (^0.22.0) None
coveralls (^2.13.1)   node-coveralls (3.0.1-1)
dateformat (^2.0.0)   node-dateformat (2.0.0-1)
ejs (^2.5.6)  ejs.js (1.0.0+dfsg1-1)
eslint-plugin-eslint-plugin (^1.2.0)  None
eslint-plugin-node (^5.1.0)   None
eslint-plugin-rulesdir (^0.1.0)   None
eslint-release (^0.10.1)  None
eslint-rule-composer (^0.1.0) None
eslump (1.6.0)None
esprima (^4.0.0)  node-esprima (4.0.0+ds-2)
esprima-fb (^15001.1001.0-dev-harmony-fb) node-esprima-fb 
(15001.1001.0-dev-harmony-fb-1)
istanbul (^0.4.5) None

Re: [Enigmail] avoiding openpgp.js for enigmail in debian

[Daniel Kahn Gillmor]

On Sat 2018-05-26 18:31:46 +0200, Patrick Brunschwig wrote:
> Let's be fair ;). OpenPGP.js is LGPL, which is considered open source.
> The fact that Debian cannot handle the way that OpenPGP.js is built does
> not make it (or Enigmail) less open source, but is primarily a
> Debian-issue.

Yes, i agree -- i'm not claiming that Enigmail is itself non-free, i'm
saying that it depends on software that i can't sort out how to build
reliably, which means i don't feel comfortable including that software
in debian.

> I agree that it would be nicer if Enigmail were to build OpenPGP.js by
> itself, but just like you: I don't have the capacity for this.

understood :( I have the sense that the javascript ecosystem doesn't
believe that reliable builds that don't require the internet are
important, and that we should just all use npm and an active internet
connection for everything.  I would love it if i felt comfortable doing
that, but it doesn't seem responsible to me.

> Many Autocrypt-related functions are not fully supported by GnuPG:
>
> 1. creating the Autocrypt header: the key is specified to contain
> exactly one UID one public/signing key and one encryption key. There is
> no function in GnuPG to extract this from a key. Users that have many
> UIDs or many subkeys keys cannot use Autocrypt with GnuPG because the
> header gets too long. See https://sourceforge.net/p/enigmail/bugs/731/

ok, so this might be typically solvable if we can get GnuPG to fix:

   https://dev.gnupg.org/T3622
   https://dev.gnupg.org/T3804

In the worst case, if the user is manipulating their keys outside of
autocrypt and adding a bunch of new subkeys, the autocrypt header might
be longer, but we can simply encourage people using autocrypt to not do
that for the moment (so that we don't have to deal with this
corner-case).

Alternately, i can look into adding a GnuPG export option that does
something like "export-autocrypt" which is designed to explicitly narrow
down what is exported.

> 2. Using GnuPG, you cannot guarantee that the Autocrypt Setup Message
> (ASM) is encrypted with a specific password. See https://dev.gnupg.org/T3277

https://dev.gnupg.org/T3277 shows that there is a capability to do it,
but you have to dance a delicate dance to ensure that it's done.  I'll
see what i can do to dance that dance in enigmail :/

> 3. You cannot check the packet list with GnuPG (which is again required
> before importing the ASM. Werner repeats that --list-packets is not
> meant for productive tools.

I agree that using --list-packets is not acceptable, since GnuPG
upstream refuses to support it as an API.

> Run the unit tests in package. I think that almost everything covered by
> tests, except for the ASM.

thanks, i'll make sure to run both "check" and "unit".  I note that i
can't run the "eslint" part of the test suite on the debian build
daemons, since eslint also hasn't been packaged yet for debian:

https://bugs.debian.org/743404

clearly, the javascript ecosystem in debian is struggling :(

If there's anything that you think needs eslint to ensure that things
are OK, please let me know!

> Enigmail is still usable in a sensible way without OpenPGP.js, and this
> will remain for quite a while. You'd need to cut off some parts, but
> these are not core functions. Probably the only exception is importing
> of keys, which would need some re-thoughts.

I'm glad to hear this, and i hope i can pull off these changes as
needed.  I'll likely ask you for help if i get stuck, but i really
appreciate your guidance so far.

--dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] avoiding openpgp.js for enigmail in debian

[Daniel Kahn Gillmor]

hi patrick and other enigmail folks--

modern enigmail (2.0+) includes a copy of openpgp.js.  It does not
appear to be built from source, but is instead a straight copy of a
generated block of javascript from the OpenPGP.js git repo (the
node/javascript community appears to have a common pattern of committing
their post-compilation artifacts).

Debian requires code to be built from the preferred form of
modification, so this blob isn't really appropriate in debian.

The obvious fix ("plan A", as it were) would be to build OpenPGP.js from
source in debian, and then make enigmail depend on that.  however, i've
had a very difficult time getting that to happen cleanly.  the
dependency trees in that ecosystem are quite deep, and i don't have the
bandwidth to package (and retain responsible maintainership for) the
dozen (or more‽)  node/javascript packages i would need to add to debian
in order to get OpenPGP.js packaged for debian.

So i'm leaning toward plan B, which is to remove OpenPGP.js from
enigmail when shipped with debian, and to figure out how to minimize the
harm/damage.

One advantage we have in this context is that in debian we can
explicitly set hard dependencies on versions of GnuPG.  so if we need a
feature only available in GnuPG 2.2.3 or later, we can just make that
dependency explicit.

If anyone has a proposal for other ways to deal with this, or an
argument why this is a problematic approach, i would be happy to hear
it.  I would also welcome any help in packaging OpenPGP.js for debian,
if anyone is interested in doing so.

I just wanted to give folks a heads-up of where i'm at in this
frustrating process; to apologize for the delay in dealing with this;
and to solicit any constructive feedback i can get.

Regards,

--dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] 2.0.5 fails "make check" due to missingMdcError (should be mdcError?)

[Daniel Kahn Gillmor]

Hi all--

i've just filed this pull request to fix a problem with "make check"
during a build of enigmail 2.0.5:

  https://gitlab.com/enigmail/enigmail/merge_requests/1

I'm a little surprised to see a signed tag that doesn't pass "make
check" -- is "make check" run before every release?

   --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] gpgv

[Daniel Kahn Gillmor]

On Thu 2018-04-19 23:54:40 +0200, Andy Weber wrote:
> The process seems to be spawned by dirmngr.exe, ptree looks like this:
>
> + "C:\Program Files (x86)\GnuPG\bin\dirmngr.exe" --daemon --homedir
> C:/Users//AppData/Roaming/gnupg
>     + dirmngr.exe (Suspended and fails to resume)
>     + "C:\Program Files (x86)\GnuPG\bin\gpgv.exe"
> --enable-special-filenames --status-fd=2 --keyring "C:\Program Files
> (x86)\GnuPG\share\gnupg\distsigkey.gpg" -- -&1072 -
>     + \??\C:\WINDOWS\system32\conhost.exe 0x4

if it's dirmngr invoking gpgv, then it's likely being triggered by
dirmngr's attempt to check that the latest version of gpg is available.

Can you run the following commands from cmd.exe successfully?

gpgconf --query-swdb
gpg-connect-agent --dirmngr 'loadswdb --force' /bye

that might help you to debug the problem a bit more directly than
dealing with enigmail in the loop.

--dkg

___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] check-trustdb speed [was: Enigmail v2.0 breaks split-gpg (Qubes OS)]

[Daniel Kahn Gillmor]

On Tue 2018-03-27 15:17:19 +0200, Patrick Brunschwig wrote:
> The command line option exists for many years in GnuPG. The only new
> thing is that Enigmail tries to better control when the trustdb is
> checked, such that importing keys into large keyrings are quicker. For
> example, my keyring contains ca. 700 keys; importing a new key takes
> several minutes without that option.

Arguably, this is an issue with upstream GnuPG, and it has not been
addressed there:

https://dev.gnupg.org/T2019

Additional feedback or suggestions for improvement upstream would
probably head in the right direction for avoiding this problem in the
future.

--dkg

___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] feedback from initial enigmail setup (using wizard)

[Daniel Kahn Gillmor]

On Thu 2018-03-08 08:34:34 +0100, Patrick Brunschwig wrote:
> Interestingly, *two* usability studies have suggested that the
> explanations before were insufficient. The current text is actually the
> suggested text from the last usability study.

i wonder how the usability studies were framed that they came to that
conclusion.  from the discussions in the Autocrypt project, we seem to
have a fairly robust user story that never mentions the concept of
keys to the user at all.

If the usability studies were expected to improve the outcome of "how
well do you understand public key cryptography" then i agree tha tthe
text is insufficient.  If the question is "can you send encrypted mail"
then maybe the answer is that it's too much text :/

i'm a big fan of letting explorers explore, but not a big fan of
expecting people to click through stuff they don't understand while
thinking "blah blah blah..."


>>  * When i click the "Create Revocation Certificate" button, i get a
>>popup dialog box saying "The revocation certificate could not be
>>created", with a "close" button.  When i click "close", it takes me
>>to a file chooser.  Then i choose a file, and it shows me the same
>>"revocation certificate could not be created" dialog box.  I can
>>cycle between these things indefinitely.
>> 
>>When i finally tire of this, the only option left to me is to cancel
>>the wizard.  It prompts me with something like "are you sure you want
>>to cancel the wizard?" with choices of "close" or "continue".  I feel
>>bad because i do want to continue, but i choose "close".   Then, when
>>i go back into the Setup Wizard via the Enigmail submenu, it just
>>asks me to choose a key (my now-existent key is present, so i choose
>>it), and then it tells me i'm done (without offering to create a
>>revocation certificate).
>
> I'll look into this. Which version of gpg are you using exactly?

this was gpg 2.2.5, but i realize now after trying to replicate it the
problem appears to have come from a pinentry breakage on the specific
account i was using.  Not enigmail's fault, but it'd still be good to
handle any failure to create a revocation certificate more gracefully,
rather than leaving the user feeling stuck.

> Strange. Is LC_ALL defined in your environment? If not, where is the
> "locale" executable (/usr/bin/locale ?)

0 dkg@alice:~$ which locale
/usr/bin/locale
0 dkg@alice:~$ locale
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
0 dkg@alice:~$ echo $LANG
en_US.UTF-8
0 dkg@alice:~$ 

hth,

  --dkg

___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] feedback from initial enigmail setup (using wizard)

[Daniel Kahn Gillmor]

Hi all--

Today i have done several trial run-throughs, thunderbird 1:52.6.0-1+b1
+ enigmail 2:2.0~beta2-1 on debian testing/unstable.  I have a few
observations and recommendations about the setup wizard.

I chose the "standard configuration (recommended for beginners)".  all
the recommendations below are only for people using the wizard in
"standard mode".




 * New key creation password requirement.  Currently the wizard requires
   that the user enter a password of at least 8 characters.  It's not
   clear that treating this as a hard requirement is a good idea.
   Having the "password strength" meter gives the user some sense of how
   good their password is.  But perhaps we can let users make their own
   decisions about when their password is chosen.  There are legitimate
   "opportunistic" e-mail encryption approachs that discourage the use
   of passwords entirely.

   Recommendation: remove the hard requirement of 8 chars minimum.

 * The "create key" part of the dialog box has scrollbars, which makes
   it pretty awkward to use:


   Recommendation: resize the dialog box to not need the scrollbars

 * The text in the "create key" dialog box is quite a lot.  It's much
   more than any beginner who chose a standard configuration will
   probably read.

   Recommendation: Remove all of the current text.  Under the
   "Account/User ID" dropdown box, include something like this:

   Enigmail lets you send and receive end-to-end encrypted messages
   with this e-mail account.  Only this Enigmail profile will be
   able to read these encrypted messages.

   To protect these messages further, you can lock them with a
   password below.  All encrypted messages will be unreadable
   without the password.

   Optionally, we could hide the entire password-setting UI inside a
   collapsible frame labeled "Set end-to-end password"

   The text about umlauts and character classes should be shown only
   when the user enters a password that has the properties that it is
   warning about. (e.g. maybe the field that currently shows "passphrase
   should contain at least 8 characters")

 * The circled red+white X that shows when one of the password fields is
   bad is weirdly stretched.

   Recommendation: fix the aspect ratio of the image :)

 * The "passphrase should contain at least 8 characters" warning appears
   only after the user's focus *leaves* the password field, which is
   confusing.

   Recommendation: that warning box should be dynamically updated as the
   user types.

 * "Revocation Certificate Creation" -- it's awesome that enigmail
   encourages good key management practices, for those people who want
   to explicitly mangae their keys, but it's really frustrating for a
   "standard" configuration to not be able to proceed until a revocation
   certificate is generated.

   Recommendation: make "Create a revocation certificate" an optional
   button available during an earlier phase of the dialog box (maybe
   next to the "Set end-to-end password" collapsible choice recommended
   above?).  This would allow the user to choose a location for the
   revocation cert early in the process if they want it.  Do not force
   the user to generate a revocation certificate (modern versions of
   GnuPG auto-generate a revocation certificate anyway).


 * When i click the "Create Revocation Certificate" button, i get a
   popup dialog box saying "The revocation certificate could not be
   created", with a "close" button.  When i click "close", it takes me
   to a file chooser.  Then i choose a file, and it shows me the same
   "revocation certificate could not be created" dialog box.  I can
   cycle between these things indefinitely.

   When i finally tire of this, the only option left to me is to cancel
   the wizard.  It prompts me with something like "are you sure you want
   to cancel the wizard?" with choices of "close" or "continue".  I feel
   bad because i do want to continue, but i choose "close".   Then, when
   i go back into the Setup Wizard via the Enigmail submenu, it just
   asks me to choose a key (my now-existent key is present, so i choose
   it), and then it tells me i'm done (without offering to create a
   revocation certificate).

   Recommendation: for those people who want to save a revocation
   certificate, make sure that the file save actually works. Looking in
   the debug log, i don't see any problem with revocation cert
   generation on the GnuPG side, and i don't see anything else in the
   enigmail logs after revocation to indicate why things are failing:


2018-03-07 19:07:52.001 [CONSOLE] enigmail> /usr/bin/gpg --charset utf-8 
--display-charset utf-8 --no-auto-check-trustdb --no-tty --status-fd 1 
--logger-fd 1 --command-fd 0 -a -o /home/tester/xx.asc --gen-revoke 
0xF730CBF596C0AFB4
2018-03-07 19:07:52.033 [DEBUG] keyEdit.jsm: GpgEditorInterface.processLine: 
'[GNUPG:] KEY_CONSIDERED 

Re: [Enigmail] [ANN] Enigmail 2.0 Beta 2 available

[Daniel Kahn Gillmor]

On Thu 2018-03-01 08:29:54 +0100, Patrick Brunschwig wrote:
> Sourceforge is fully operational again since at least a week. I create
> all builds from my build server, which would always at first update from
> git at  enigmail-source>.

I've been using git://git.code.sf.net/p/enigmail/source for ages, and it
is not working at all, so i have to differ about "fully operational".

I'm assuming that you don't actually want me to use pbrunschwig@ in the
URL?

> So far, I did nothing more than "reserve" the name, such that nobody
> else take it (unlike "enigmail" on Github). I assume you're "dkg" on Gitlab?

yep, i'm "dkg" on gitlab and github and pretty much everywhere just to
keep things simple :)

I wonder whether we should complain to the github folks about name
squatting.  i don't know what their policy is there.

 --dkg

___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] [ANN] Enigmail 2.0 Beta 2 available

[Daniel Kahn Gillmor]

On Wed 2018-02-28 18:35:36 +0100, Patrick Brunschwig wrote:
> I'm pleased to announce the 2nd beta version of Enigmail 2.0.

thanks for this work!  I note that sourceforge appears to still be in
disaster recovery mode, as it has been for several days.  Do you have a
mirror of the git repository set up someplace?  It'd be nice to be able
to review the actual history behind this release, not just the tarball.

I see:

   https://gitlab.com/enigmail/enigmail/project_members

but there's nothing in the repository :/ if you want to make me a member
of that group, i'd be happy to populate the repo so that all you have to
do is add a git remote.  There's no reason to use only one public-facing
revision control archive, now that we're using proper DVCS :)

   --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] "Initiate Autocrypt Key Transfer" should not say "Key"

[Daniel Kahn Gillmor]

In the preferences dialog of enigmail 2.0-beta1, the "Transfer Settings"
tab has a button "Initiate Autocrypt Key Transfer".

Autocrypt goes to great pains to avoid exposing users to the term "Key",
so it seems odd to see "Key" paired with "Autocrypt" here, especially
since the tab itself does not have "Key" in its title.

Could this be "Autocrypt Setup Transfer" or "Initiate Autocrypt Setup?
or something like that?

The dialog as a whole is too much text for most users to read, in this
era of short attention spans.  I recommend splitting it into three
simple buttons, something like:


 [ Set up another Autocrypt e-mail app ]  (_What's_Autocrypt?_)

 [ Back up your Enigmail settings ]

 [ Restore Enigmail settings from backup ]

I'm imagining that _What's_Autocrypt?_ would be a link that takes the
user to some explanatory page at https://autocrypt.org/ .

(obviously, if enigmail is not in a state to be able to initiate an
Autocrypt Setup Message, the first button should be disabled; perhaps
adding a tooltip or a "why is this disabled?" link would be friendly in
that situation)

Maybe with this setup, we can do away with all the rest of the text
in that pane entirely?

   --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] "Let subject unprotected" needs improvement

[Daniel Kahn Gillmor]

Hi there--

thanks for implementing protected headers in enigmail 2.0!  this is very
exciting :)

The dialog box that pops up on send currnetly has one button labeled
"Let subject unprotected"

This doesn't sound right to my en_US ears.

Some other alternatives that sound better:

  Leave subject unprotected

  Leak subject line

  Don't protect subject


hope this helps,

 --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] compose toolbar overlay -- two "Enigmail Encryption Info" choices

[Daniel Kahn Gillmor]

I'm using enigmail 2.0~beta1-1 from debian experimental.

When looking to "customize" the compose toolbar, i see two options that
look pretty much identical to each other, both labeled "Enigmail
Encryption Info" :


it'd be good to:

 * make the name shorter so that it's visible/understandable during
   customization without hovering for the tooltip

 * either distinguish one from the other, or remove one of them
   entirely.

Thanks for working on enigmail!

   --dkg
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] [PATCH] express ordered build rules

[Daniel Kahn Gillmor]

On Thu 2018-02-15 00:44:28 -0500, Daniel Kahn Gillmor wrote:
> By expressing the rule to create package/buildDate.jsm as a way to
> target buildDate.jsm, make will force it to happen in order.
>
> otherwise, parallel build processes might try to invoke the deploy
> rule first.
>
> Note that if your goal is to rebuild buildDate.jsm each time you
> build, this changeset not work, because once created, buildDate.jsm
> will not be updated.
>
> However, in that same case, a parallel build offers no guarantees that
> buildDate.jsm will actually be updated before the deploy rules fires,
> so a parallel build could also include the older (unupdated) version
> of package/buildDate.jsm, non-deterministically.

btw, if the goal is really to always recreate buildDate.jsm, then it
should be removed from MODFILES and the three-step file generation can
be added directly to rule under the "deploy" target.

Either this approach or the proposed patch is the right thing to do;
both are better than the current state, which behaves poorly with
parallel builds.

 --dkg

___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] [PATCH] express ordered build rules

[Daniel Kahn Gillmor]

By expressing the rule to create package/buildDate.jsm as a way to
target buildDate.jsm, make will force it to happen in order.

otherwise, parallel build processes might try to invoke the deploy
rule first.

Note that if your goal is to rebuild buildDate.jsm each time you
build, this changeset not work, because once created, buildDate.jsm
will not be updated.

However, in that same case, a parallel build offers no guarantees that
buildDate.jsm will actually be updated before the deploy rules fires,
so a parallel build could also include the older (unupdated) version
of package/buildDate.jsm, non-deterministically.
---
 package/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/Makefile b/package/Makefile
index 2c50e214..f7b9ee0e 100644
--- a/package/Makefile
+++ b/package/Makefile
@@ -107,7 +107,7 @@ ENIG_BUILD_DATE=$(shell TZ=UTC date $(DATE_FMT) -d 
"@$(SOURCE_DATE_EPOCH)" 2>/de
 TZ=UTC date -r "$(SOURCE_DATE_EPOCH)" $(DATE_FMT) || \
 TZ=UTC date $(DATE_FMT) )
 
-all: libs deploy
+all: deploy
 
 deploy: $(PREFFILES) $(MODFILES)
$(DEPTH)/util/install -m 644 $(DIST)/modules/preferences $(PREFFILES)
@@ -118,7 +118,7 @@ clean:
$(DEPTH)/util/install -u $(DIST)/modules/preferences $(PREFFILES)
$(DEPTH)/util/install -u $(DIST)/modules $(MODFILES)
 
-libs:
+buildDate.jsm:
echo '"use strict";' > buildDate.jsm
echo 'var EXPORTED_SYMBOLS = ["EnigmailBuildDate"];' >> buildDate.jsm
echo 'const EnigmailBuildDate = "$(ENIG_BUILD_DATE)";' >> buildDate.jsm
-- 
2.15.1


___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Fwd: PGP key expires in 3 days: 0x8EE66C320E62EFA8 (it can be extended)

[Daniel Kahn Gillmor]

Hi David--

On Tue 2018-02-06 13:57:47 -0500, David wrote:

> I received this in today's email. Some of the information is correct but
> his main data, the expiry date, is completely incorrect.

i don't know about "completely incorrect" -- but maybe his keyserver
isn't syncing with others?  it looks like you updated your OpenPGP
certificate's expiration date with a self-sig on 2016-01-24.  Before
that update was merged to your cert, it would indeed have looked like
your OpenPGP certificate would expire on the date mentioned in the
e-mail.

> Is anyone familiar with this person or this site?

nope, sorry.  did you try writing him directly?  Maybe it's worth asking
him whether his keyserver is correctly synchronizing with the rest of
the pool?

it does seem like a nice service to offer to the public, if only it were
up-to-date :)

--dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Enigmail incorrectly complains about tz announcements

[Daniel Kahn Gillmor]

On Wed 2018-01-24 18:44:58 -0800, Paul Eggert wrote:
> I recently got a bug report from one user, who says that Thunderbird 
> complains about this email. I can reproduce the problem by viewing the 
> attached email with Thunderbird 52.5.2 (64-bit) which is using Enigmail 
> version 1.9.9 (20171222-0011). Thunderbird says "Enigmail Error - No 
> valid armored OpenPGP data block found".

arguably, this is a bug in enigmail's attempts to handle inline-signed
messages.  I think that enigmail should treat this as a "failed
signature", which is to say -- enigmail should simply ignore the
situation.  Messages which are not correctly signed have no semantic
difference from messages which are not signed at all.

I recommend that if enigmail can detect this situation it should leave
the message untouched; treat it as an unsigned message; and provide no
error or warning UI.

thanks for your work on tzdata, btw!

  --dkg

___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Missing features for Enigmail

[Daniel Kahn Gillmor]

On Wed 2018-01-24 16:11:58 -0500, Jean-David Beyer wrote:
> On 01/24/2018 10:17 AM, Neil D. Donovan wrote:
>> 2) Automatic decryption of received encrypted emails to the folder on
>> the email server
>
> If I were sending you an encrypted e-mail, I presume I wish you to be
> able to read it, but I surely would not wanting you to share its
> contents with anyone else. So if I knew you would even be storing the
> decrypted version of my email anywhere else

I agree with this sentiment.  Storing the cleartext (or
cleartext-equivalent) on a remote untrusted server, or someplace that
makes it easy to get to, seems like a bad idea, and a loss of end-to-end
security that the sender is likely to expect.  That said…

> (or even on your own computer)

i think this goes too far.  Even in the most tightly-controlled
end-to-end scenario, my own computer is going to see a cleartext version
of this message.  Whether my computer sees it briefly, or for a longer
period of time, the local user's endpoint still has access to it.

Given that there can be serious user experience wins from having a
locally-cached cleartext copy (or the equivalent, e.g. an index), it
seems like a bad idea to discourage people from using encrypted mail.
wouldn't you rather that they have an incentive to use encrypted mail
*more*, rather than falling back to cleartext?

--dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Feature request: forwarding encrypted messages.

[Daniel Kahn Gillmor]

On Mon 2018-01-15 12:33:54 +0200, Lachezar Dobrev wrote:
>   Yes, I am using "Forward as Attachment".
>   Typically because I'd like to forward the attachments to the
> original message too.
>   I almost always use explicitly the Menu item to forward the mail as
> an attachment.

right, i think the problem you're running into is that "forward as
attachment" means both "include original attachments" and "forward the
message as I received it".

You're saying "i'd like to not forward it as i received it, because the
new recipient won't be able to read it".

right?

So i think you're asking for a new type of forwarding "forward as
attachment but re-encrypted to new recipient" -- is that right?

I think that makes sense as a request, but i should warn you that it
might be a lot of work to implement.  Patrick can speak to that better,
though.

>   P.S. Too many "I"s. The message might look a bit narcissistic, which
> is not intended.

no worries -- "I" statements are useful description in a bug report or a
feature request :)

   --dkg




signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Feature request: forwarding encrypted messages.

[Daniel Kahn Gillmor]

On Fri 2018-01-12 20:43:39 +0100, Andreas Hirsch wrote:
> I suppose You are mixing up 'forwarding' and 'bouncing'
>
> If You forward a message, the old message will be decrypted and copied
> into a new message. The new message would be correct encrypted for the
> new recipients.

i think this depends on whether you are forwarding "inline" versus
forwarding "as attachment".

in the thunderbird preferences dialog, look at the "composition"
section, "General" tab, for "Forward messages" to see what you've got
in your current setup.

 --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] What does "Beware of leaking sensitive information" warning mean?

[Daniel Kahn Gillmor]

On Fri 2018-01-12 15:58:25 +0200, Lachezar Dobrev wrote:
>   P.S. Stripped quoted messages as they seem to produce Enigmail errors.

this seems like it might be a separate issue.  perhaps you could start a
new thread, describing specifically what enigmail errors you're seeing
when you do not strip quoted messages?

(stripping unnecessary quoted text is good practice; i don't want to
encourage people to leave unnecessary quoted text in their e-mails.  But
if they do leave large blocks of text for whatever reason, they
shouldn't have errors as a result)

 --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] What does "Beware of leaking sensitive information" warning mean?

[Daniel Kahn Gillmor]

On Wed 2018-01-03 14:39:55 +0200, Lachezar Dobrev wrote:
>   Recently I've been greeted with a red warning every time I try to
> reply to an encrypted message saying:
>
>   "Beware of leaking sensitive information - partially encrypted email."
>
>   With a Details button that shows a pop-up:
>
> """
> The message you are editing was partially encrypted. That is, the
> message contains unencrypted and encrypted parts. Some encrypted
> message parts may even be invisible to you.
>
> If the sender was not able to decrpyt the message parts originally, it
> is likely that you only got the email with some surrounding
> unencrypted text in order to make you reveal the encrypted
> information.
> """
>   (the "decrpyt" is a spelling mistake as is)
>
>   What does this actually mean, and why does it show on every message
> I try to reply to?
>
>   I have checked, and the mail is encrypted with the same two keys
> that the reply is going to be encrypted with: one is mine, the other
> is the one for the original sender.

This is about CVE-2017-17844.  The attack these warnings aim to mitigate
against goes like this:

 * attacker gets a copy of an encrypted message X that had been sent to
   you

 * attacker creates a new message Y to you, and embeds encrypted message
   X somewhere in the tail of message Y (the long chain of quoted,
   attributed text that everyone ignores because top-posting is somehow
   the expected norm).

 * you receive message Y, and reply to it (composing a new e-mail to the
   attacker).

 * without the warning, it's likely that enigmail will decrypt the
   quoted message and place the cleartext in the new reply message.


However, it sounds like you're seeing this warning trigger on every
e-mail reply, which seems unlikely to be the intended situation.

What do your inbound e-mails look like?  how are they structured?  are
they PGP/MIME, or inline PGP?  if they're inline PGP, is there a lot of
text around the encrypted blob?

 --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] [ANN] Enigmail v1.9.9 available

[Daniel Kahn Gillmor]

Thanks very much for this work, Patrick!  And thanks to Posteo and
Mozilla for funding this research.

On Tue 2017-12-19 08:45:29 +0100, Patrick Brunschwig wrote:
> [1]
> 
> [2] 

Are there CVE numbers assigned to these?

I see 6 vulnerabilities listed that seem CVE-worthy to me:

 * TBE-01-002 Enigmail: Weak Parsing Causes Confidentiality Compromise 
(Critical)

(the description of this one is a bit confused -- it's not clear who
 is sending the e-mail, or who the attacker is, or how the message
 is specifically encrypted.  it also references TB-01-004, which
 isn't listed in the excerpt)

 * TBE-01-005 Enigmail: Replay of encrypted Contents leads to Plaintext Leak 
(High)

 * TBE-01-021 Enigmail: Flawed parsing allows faked Signature Display (Critical)

 * TBE-01-001 Enigmail: Insecure Random Secret Generation (Low)

 * TBE-01-003 Enigmail: Regular Expressions Exploitable for Denial of Service 
(Low)

 * https://sourceforge.net/p/enigmail/bugs/709/  Enigmail: Signature Spoofing 
Attacks using multipart/related 

-


If you've already got CVEs assigned, can you report them?  If you don't,
and you want to request them yourself, you can get them here:

   https://cveform.mitre.org/

If you don't want to bother, i can request CVEs for you and report back
on-list.

Please let me know what you prefer to do about getting CVEs here!

   --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] enigmail 1.9.9 release?

[Daniel Kahn Gillmor]

On Sat 2017-12-16 11:54:57 +0100, Patrick Brunschwig wrote:
> The release is not yet published/announced because I'm waiting for
> addons.mozilla.org to get it approved, such that the majority of the
> users get it simultaneously with the announcement.

Ok, but i've already made it available to debian unstable users :)

I'm happy to be able to get the backports of the Cure53 audit out to
people.

do let me know if you have any concerns about distributing it to debian
users.

--dkg

___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] enigmail 1.9.9 release?

[Daniel Kahn Gillmor]

hey Patrick and other good enigmail users--

I see from git that enigmail 1.9.9 has been tagged, but i don't see it
for download in either of these places:

   https://www.enigmail.net/index.php/en/download/source-code
   https://www.enigmail.net/index.php/en/download

I do note that the tarball is actually available (as is the .asc
detached cryptographic signature) at:

  https://www.enigmail.net/download/source/enigmail-1.9.9.tar.gz
  https://www.enigmail.net/download/source/enigmail-1.9.9.tar.gz.asc

Is there a reason that this release isn't more widely announced?

I appreciate that it appears to have a bunch of bugfixes from the Cure53
audit.

--dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] On Displaying Signatures

[Daniel Kahn Gillmor]

On Fri 2017-11-10 18:37:08 +0100, Patrick Brunschwig wrote:
> On 10.11.17 16:25, Daniel Kahn Gillmor wrote:
>> How does the user know where the first part ends and the second part
>> begins?
>
> There's a horizontal line between every MIME part.

very subtle :(

 --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] On Displaying Signatures

[Daniel Kahn Gillmor]

On Fri 2017-11-10 11:12:21 +0100, Patrick Brunschwig wrote:
> That's a very important point. Option B is not possible without hacking
> deeply into Thunderbird - I would not know how to go that way.

:(

> I think the following variant of A is a good compromise:
>
> If the *first* displayed MIME part is signed, then the signature is
> shown with an indication that only the 1st message part is signed. If
> any other MIME part is signed, then no information about the signature
> is displayed.

How does the user know where the first part ends and the second part
begins?

--dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] On Displaying Signatures

[Daniel Kahn Gillmor]

On Thu 2017-11-09 16:30:45 +0100, Werner Koch wrote:
> On Mon,  6 Nov 2017 11:46, whi...@posteo.net said:
>
>> Why not display exactly what GnuPG reports concerning a signature? Leave
>> it up to the user to make his own value judgments.
>
> That is what I was about to reply ;-).
>
> In fact we have spend weeks of work to come of with a useful
> representation of signature stati.  Not everything has been implemented
> but eventually we will update our evaluation of the status as
> represented by the GPGME_SIGSUM_ flags.
>
> See
>
>   https://wiki.gnupg.org/EasyGpg2016/AutomatedEncryption
>   https://wiki.gnupg.org/EasyGpg2016/OutlookUi

There's a lot of text on both of these pages.  I haven't read them all.
But the first page does say:

There should only be prominent information when reading a signed mail if:

   There is additional information that the sender really is the
   intended communication partner. (Level >= 2)

In other words, we do not display that a message is unsigned, and we
do not display that a message has a bad signature. These are treated
equivalently. (See below.)

This sounds roughly equivalent to what Patrick wrote to me.  And not at
all like what Whitey is suggesting.  So i think i misunderstood your
reply to this thread earlier -- i had read you as agreeing with Whitey
when i read the thread offline and didn't have access to the wiki links
above.

Apologies for the confusion!

  --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] On Displaying Signatures

[Daniel Kahn Gillmor]

Hi Patrick--

Thanks for documenting this.

On Sun 2017-11-05 12:06:54 +0100, Patrick Brunschwig wrote:
> We *only* display signature information if *all* of the following
> conditions are satisfied:

One thing not covered by this discussion is how enigmail will deal with
signatures that do not cover the entire message (for example, if mailman
wraps the message body in a multipart/mixed and appends a footer).

Assuming that the signature over the subpart meets all of the other
requirements you've already enumerated, I recommend one of two choices
in that case:

 A) not showing the signature at all (so that users don't have to guess
at which part of the message was actually signed)

 B) indicating the valid signature, but treating the signed part as the
entire message body (that is, suppressing the unsigned part so that
it is not shown to the user).

If option (B) is taken, then optionally a button could be added
"[display message as received]" that would convert the display to option
(A).

Regards,

--dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] [PATCH] autocrypt: type should always come first and addr should not, have quotes

[Daniel Kahn Gillmor]

On Mon 2017-09-25 08:24:51 +0200, Patrick Brunschwig wrote:
> On 22.09.17 16:36, Karissa McKelvey wrote:
>> From 93ae4c9f49fedeead1b6dd80a31f325a6fba5d30 Mon Sep 17 00:00:00 2001
>> From: okdistribute 
>> Date: Fri, 22 Sep 2017 16:07:17 +0200
>> Subject: [PATCH] autocrypt: type should always come first and addr should 
>> not have quotes
>
> Why did you resend the patch to the mailing list? The merge request on
> Sourceforge was perfectly fine and is already closed.

I suggested that Karissa send the patch to the mailing list, because i
haven't seen the sourceforge merge request approach used on enigmail
before, and didn't know whether you were monitoring it there.

Would you prefer that future patches come in as merge requests on
sourceforge?  If so, maybe we should update the Developer's Wiki to make
that prominent.

Thanks for merging these!

  --dkg

___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] U+2705 HEAVY WHITE CHECK MARK (for key import)

[Daniel Kahn Gillmor]

On Thu 2017-07-06 08:23:00 +0200, Patrick Brunschwig wrote:
> On 05.07.17 22:04, Daniel Kahn Gillmor wrote:
>
>> i see the use of unicode code point U+2705 (HEAVY WHITE CHECK MARK) in
>> importInfoSuccess as broken with some font sets.
 [...]
> I think I better replace the label by an image.

sounds reasonable.  I've opened
https://sourceforge.net/p/enigmail/bugs/694/ to track that suggestion.

Regards,

 --dkg

___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] ALLOW PASTING

[Daniel Kahn Gillmor]

On Thu 2017-07-06 17:35:21 +0200, Ludwig Hügelschäfer wrote:
> On 06.07.17 15:12, Lancon Erocan wrote:
>> I know there is indeed security issue on auto-filling, but there is no
>> reason to disallowing pasting. In that case I have no mean to input a
>> /*REALLY */secure password generated from my password manager.
>> Pls, /*DO NOT*/ F**K with pasting.
>
> Please moderate your tune. This not considered the right vocabulary
> here. Alos, you're barking up the wrong tree: Enigmail does NOT supply
> the Pinentry dialog.

fwiw, many newer versions of pinentry tend to allow pasting, but given
that Lancon hasn't mentioned even what platform he's using (let alone
which pinentry or which version) i don't know how to help him debug.

Lancon, if you don't feel like cursing any more, feel free to follow up
over on gnupg-us...@gnupg.org with details about your system and we can
have a discussion about pinentry and the copy/paste mechanism.

Regards,

 --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] U+2705 HEAVY WHITE CHECK MARK (for key import)

[Daniel Kahn Gillmor]

hey enigmail folks--

i see the use of unicode code point U+2705 (HEAVY WHITE CHECK MARK) in
importInfoSuccess as broken with some font sets.

here's a view of the import key dialog box on Debian with the standard
set of fonts involved:


i suspect there's a general expectation that this should be a green
circle around a white checkmark, but not all fonts have that particular
glyph (some don't have any glyph for that codepoint at all).

U+2714 HEAVY CHECK MARK seems to be a more widely-supported glyph, but
it doesn't look quite as flashy as what i imagine you're expecting.

Would there be any objection to moving to U+2714?  Or could we use an
explicit graphical icon instead so that we don't have to rely on the
vagaries of font glyphsets?

 --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] testing enigmail

[Daniel Kahn Gillmor]

hey all--

as far as i can see, enigmail's test suite is all unit tests.

are there any full-stack, UI-level tests that would make sense to run?

I was thinking of writing some sort of tests for the debian continuous
integration infrastructure (https://ci.debian.net/) that would exercise
the whole package.

Such a test could even involve setting up and running an imap and smtp
server on the local machine, generating keys, and encrypting/decrypting
mail.

Has anyone done anything like this (either in the setup process, or in
terms of automating testing of the thunderbird + enigmail UI)?

  --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] gpg-connect-agent invocations

[Daniel Kahn Gillmor]

On Tue 2017-06-06 08:17:23 +0200, Patrick Brunschwig wrote:
> On 05.06.17 17:20, Daniel Kahn Gillmor wrote:
>> i notice that in e68dfc8260ebf976ba50845e794c9fac0d262975 enigmail is
>> now invoking gpg-connect-agent, and then sending it commands on stdin.
>> 
>> if there's no intent to read responses from stdout, you can also pass
>> parameters on the command line.
>> 
>> so instead of:
>> 
>> gpg-connect-agent
>> 
>> and then writing:
>> 
>> KILLAGENT
>> /bye
>> 
>> You can just invoke:
>> 
>>gpg-connect-agent KILLAGENT /bye
>> 
>> this might be cleaner for simple invocations.
>
> You're right yes. I might change it...

Attached is a patch (untested) if you're still interested in this
cleanup.

--dkg

>From 5a36eb503f83f01524267871112555c98ca6 Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor <d...@fifthhorseman.net>
Date: Wed, 5 Jul 2017 07:25:56 -0700
Subject: [PATCH] use commandline invocations for killagent instead of stdin

---
 package/gpgAgent.jsm | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/package/gpgAgent.jsm b/package/gpgAgent.jsm
index 7bc3a3d1..ef3a71a6 100644
--- a/package/gpgAgent.jsm
+++ b/package/gpgAgent.jsm
@@ -791,14 +791,8 @@ var EnigmailGpgAgent = {
   try {
 const proc = {
   command: EnigmailGpgAgent.connGpgAgentPath,
-  arguments: [],
-  charset: null,
-  environment: EnigmailCore.getEnvList(),
-  stdin: function(pipe) {
-pipe.write("killagent\n");
-pipe.write("/bye\n");
-pipe.close();
-  }
+  arguments: ['killagent', '/bye'],
+  environment: EnigmailCore.getEnvList()
 };
 
 subprocess.call(proc).wait();
-- 
2.13.2

___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] secret keys missing trust error

[Daniel Kahn Gillmor]

Hi Christian--

Thanks for the report. i'm filling in this mail with images in-line for
future readers (after imgur removes the images) and a textual
representation for the visually-impaired, and for indexers (to make it
easier to search if a similar issue arises).

A few diagnostic questions are included at the end.

On Sat 2017-06-03 12:01:43 +0200, Christian Riechers wrote:
> Thunderbird 54.0b3, Enigmail nightly build from 05/25/17.
> This happens every once in a while when starting Thunderbird.
> http://i.imgur.com/sZGaywy.png

this is:


it shows a dialog reading:


The following of your secret keys have missing trust.
 [REDACTED]
 [REDACTED]
We recomend that you set "You rely on certifications" to ultimate in key
 properties.
 [ ] Do not show me this dialog again.

[ Open Enigmail Key Management ][ Close ]


> I click close.
>
> When that happens, Enigmail - Key Management looks like this.
> http://i.imgur.com/gUlVeV7.png

This is:


It shows the upper-right corner of the key management dialog box with
three columns, "Key validity", "Owner Trust", and "Expiry" and four rows
of keys (the key identities are not visible, it's not clear whether they.

"Key Validity" and "Owner Trust" both show "invalid", and the Expiry
column all shows 06/26/11  (presumably this means 2011 June 6, which is
in the past).


> No other keys are visible.

we don't know which keys are visible from this image, actually, or
whether the key management filter box has any text in it. does it?

> Upon restarting Thunderbird everything is back to normal.
>
> This never happened with TB52 and Enigmail 1.9.6.1.
> Is it a known issue?

Has anything else changed on your system in the meantime, or is the
only change the upgrade to TB and enigmail?  have you tried restoring
older versions of thunderbird or enigmail to see if the problem goes
away?

Some more useful diagnostics:

how large is your public keyring ?  what version of GnuPG are you
running?  how many secret keys do you have?

 --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] [ANN] Enigmail v1.9.7 available

[Daniel Kahn Gillmor]

On Sat 2017-05-13 18:50:23 +0200, Patrick Brunschwig wrote:
> I'm happy to announce the availability of Enigmail v1.9.7 for
> Thunderbird versions 45 and 52, and SeaMonkey 2.35 and newer.

thanks!  I've uploaded this to debian unstable.  Unless there are
objections here, i'm inclined to ask the debian release team to unblock
it for transition into "stretch" (the upcoming release), or if that
fails, for the next point release.

please let me know if you have any concerns around having 1.9.7 in
stretch.

   --dkg

___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] [PATCH] Allow re-certifying keys that have expired certifications.

[Daniel Kahn Gillmor]

Some people have made expiring certifications on other keys.  After
such a certification expires, they might want to re-certify with the
same key (e.g. if they've checked with the other person that they're
still using the key).

If this happens, enigmail fails obscurely ("signing failed").

In the log is:

2017-05-15 14:41:15.494 [DEBUG] keyManagmenent.jsm: 
GpgEditorInterface.processLine: '[GNUPG:] GET_BOOL 
sign_uid.replace_expired_okay'
2017-05-15 14:41:15.494 [ERROR] Unknown command prompt: [GNUPG:] GET_BOOL 
sign_uid.replace_expired_okay

I believe this patch should resolve the problem.
---
 package/keyEditor.jsm | 4 
 1 file changed, 4 insertions(+)

diff --git a/package/keyEditor.jsm b/package/keyEditor.jsm
index f1750aca..615fea4d 100644
--- a/package/keyEditor.jsm
+++ b/package/keyEditor.jsm
@@ -616,6 +616,10 @@ function signKeyCallback(inputData, keyEdit, ret) {
   else if (keyEdit.doCheck(GET_BOOL, "sign_uid.local_promote_okay")) {
 ret.exitCode = 0;
 ret.writeTxt = "Y";
+  } 
+  else if (keyEdit.doCheck(GET_BOOL, "sign_uid.replace_expired_okay")) {
+ret.exitCode = 0;
+ret.writeTxt = "Y";
   }
   else if (keyEdit.doCheck(GET_LINE, "sign_uid.class")) {
 ret.exitCode = 0;
-- 
2.11.0


___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] [mogliii] Documentation about --list-secret-keys output

[Daniel Kahn Gillmor]

The attached thread came through on gnupg-users, but the most recent
question in it (the interaction between enigmail and smartcards) might
be more relevant over here on the enigmail mailing list.

Any ideas about how to sync up enigmail's UI and smartcards?

Regards,

--dkg

--- Begin Message ---
Hi,

I got recently very confused about how secret keys on smartcards are
presented and handled in gpg.

In particular, after putting the subkeys on a Nitrokey, my output of gpg
--list-secret-keys is

sec#  4096R/XAB 2017-XX-XX [expires: 20XX-XX-XX]
uid  My name 
ssb>  2048R/XBB 2017-XX-XX
ssb>  2048R/XCB 2017-XX-XX
ssb>  2048R/XDB 2017-XX-XX

Following confusions:

1. What is the meaning of # after sec? This means that the master key is
not available (https://wiki.debian.org/Subkeys). We already have 5 lines
of text. Why not add another line such as "#: Master key not present"

2. What is the meaning of > after ssb? It means that the secret sub keys
are not present in the keyring, but on a known smartcard. This does not
come up in a google search 'gpg "ssb>"'. I only came accross another
post by accident that said that after issuing keytocard, the sub key is
deleted (when using save) and only a reference is left. Following 1.,
why not write "#: Master key not present; >: reference to secret key on
smart card"

3. This output means that there is *NO* secret key on this computer.
This is an extremely important information, but it is not evident from
the output. Enigmail makes it look like I have a private keypair. But
actually it's not. Only a reference.

4. I cannot fully delete the secret key reference by "gpg
--delete-secret-key XAB". Although it asks me for confirmation and
does not show in --list-secret-keys anymore, it still shows in enigmail
(bold for having private key) and .gnupg/private-keys-v1.d still
contains the keys. So I'm kind of stuck in limbo here. Deleting the
offending files in private-keys-v1.d is the only way to make enigmail
forget about them.

Has this discussed before? I think there was once a drive to improve
usability of gpg. Is there a place to propose a change in the output?



___
Gnupg-users mailing list
gnupg-us...@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
--- End Message ---
--- Begin Message ---
On Thu,  6 Apr 2017 05:03, mogl...@gmx.net said:

> sec#  4096R/XAB 2017-XX-XX [expires: 20XX-XX-XX]
> uid  My name 
> ssb>  2048R/XBB 2017-XX-XX
> ssb>  2048R/XCB 2017-XX-XX
> ssb>  2048R/XDB 2017-XX-XX

The man page explains the '#' under --list-secret-keys.  I just added a
description of '>' to the man page.


Shalom-Salam,

   Werner

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


pgp3V6S72u42P.pgp
Description: PGP signature
___
Gnupg-users mailing list
gnupg-us...@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
--- End Message ---
--- Begin Message ---
Dear Werner,

Thank you for the fix. I think the explanation in the manpage is more
clear now.

Any idea how to delete subkey stubs so that they show deleted in
enigmail as well?

--- a/doc/gpg.texi

+++ b/doc/gpg.texi

@@ -301,10

+301,13

@@ and other programs.
 @itemx -K
 @opindex list-secret-keys
 List the specified secret keys.  If no keys are specified, then all
-known secret keys are listed.  A @code{#} after the letters @code{sec}
-means that the secret key is not usable (for example, if it was
-exported using @option{--export-secret-subkeys}).  See also
-@option{--list-keys}.
+known secret keys are listed.  A @code{#} after the intial tags
+@code{sec} or @code{ssb} means that the secret key or subkey is
+currently not usable.  We also say that this key has been taken
+offline (for example, a primary key can be taken offline by exported
+the key using the command @option{--export-secret-subkeys}).  A
+@code{>} after these tags indicate that the key is stored on a
+smartcard.  See also @option{--list-keys}.
 
 @item --list-signatures
 @opindex list-signatures




On 04/07/2017 05:29 PM, Werner Koch wrote:
> On Thu,  6 Apr 2017 05:03, mogl...@gmx.net said:
>
>> sec#  4096R/XAB 2017-XX-XX [expires: 20XX-XX-XX]
>> uid  My name 
>> ssb>  2048R/XBB 2017-XX-XX
>> ssb>  

Re: [Enigmail] Permanently decrypt received emails

[Daniel Kahn Gillmor]

On Tue 2017-02-14 02:32:15 -0500, vv01f wrote:
> On 14.02.2017 08:20, vv01f wrote:
>> Is there any option to make it signed first intentionally in enigmail or
>> gpg to ensure this is will happen?
>
> Well, it is the standard[0], is there any otion still to intentonally
> change it?
>
> [0]: http://www.metzdowd.com/pipermail/cryptography/2014-January/019748.html

The message you're linking to talks about the structure of OpenPGP
itself.  Putting the signature outside of the encryption leaks a bunch
of metadata that most people do not want to leak.

Patrick's earlier response was:

>>> If the message was signed and encrypted in one step, then the
>>> signature will be removed as well. GnuPG does not have a
>>> functionality to extract the signature from the encryption (which
>>> would theoretically be possible). If the message was first signed
>>> and then encrypted, then the signature will remain intact.

Enigmail depends on GnuPG.  Without GnuPG having that capability,
enigmail won't be able to do this.

I've recorded the missing feature on GnuPG's upstream bugtracker here,
if you want to pursue it further:

  https://bugs.gnupg.org/gnupg/issue2958

Regards,

  --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Problem with new version of Enigmail

[Daniel Kahn Gillmor]

On Sat 2016-11-12 23:04:51 +0900, Patrick Brunschwig wrote:
> I created a new build that reverts the change causing the issue. Please
> download the following version of Enigmail:
> https://www.enigmail.net/download/nightly/enigmail-nightly-1.9.6.1.xpi

is this going to be an official release? if so, could you tag it in the
git repo?  I'm seeing reports of the problem from debian users as well.

thanks,

--dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Question: BCC makes the signature wrong?

[Daniel Kahn Gillmor]

On Mon 2016-11-07 11:40:56 -0600, Bernhard Kleine wrote:
> I have sent a signed email to several people, some of them in BCC, since
> we donot want to share email adresses. Now, in the sent order the mail
> is shown with Enigmail seal: correct signature by Bernhard Kleine.
> However in Incoming folder (since I am on the list of recipient myself)
> Enigmail grumbles: signature not tested. The difference between the two
> mails is that the BCC addresses are not shown in Incoming folder.

Are you sure those are the only two changes?  Can you save the two
messages as .eml files (right-click, "Save As...")  and compare them
with a utility like "diff" ?

If you're not sure how to do that, and you're OK with sending the .eml
files to me to compare them for you, I'm happy to help.  You can mail
them to me encrypted to key 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9.

hth,

 --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] [ANN] Enigmail v1.9.6 available

[Daniel Kahn Gillmor]

Hi Patrick--

On Sat 2016-11-05 12:35:14 -0400, Patrick Brunschwig wrote:
> I'm happy to announce the availability of Enigmail v1.9.6 for
> Thunderbird versions 38, 45 and newer, and SeaMonkey 2.35 and newer.

Thanks for this release!  I notice that there is no git tag on
sourceforge:

git clone git://git.code.sf.net/p/enigmail/source enigmail
cd enigmail
git tag -l | grep 1.9.6

Can you sign a tag and push it?

Thanks,

--dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] [ENIGMAIL-1.9-BRANCH PATCH] keep options distinct

[Daniel Kahn Gillmor]

On Sat 2016-10-29 10:49:23 -0400, Patrick Brunschwig wrote:
> On 29.10.16 16:26, Daniel Kahn Gillmor wrote:
>> On Sat 2016-10-29 05:09:12 -0400, Patrick Brunschwig wrote:
>>> The problem is that there is no output on stderr, even though
>>> --status-fd 2 is specified. I added --no-verbose because "verbose"
>>> options in gpg.conf make gpg ignore --status-fd 2. Apparently there is
>>> something more in your gpg.conf file with the same result.
>> 
>> I think that the command that we're talking about is:
>> 
>>/usr/bin/gpg --charset utf-8 --display-charset utf-8 --use-agent --batch 
>> --no-tty --status-fd 2 --no-verbose --list-packets
>> 
>> Is that right?
>
> Right, this can't be the problem.
>
> The difference between your log file:
>
> 2016-10-28 14:35:35.523 [DEBUG] execution.jsm:
> EnigmailExecution.fixExitCode: agentType: gpg exitCode: 0 statusFlags
> undefined
> 2016-10-28 14:35:35.523 [CONSOLE]
> 2016-10-28 14:35:41.812 [DEBUG] enigmailMessengerOverlay.js:
> updateOptionsDisplay:
>
> and mine:
>
> 2016-10-29 16:44:30.301 [DEBUG] execution.jsm:
> EnigmailExecution.fixExitCode: agentType: gpg exitCode: 0 statusFlags
> undefined
> 2016-10-29 16:44:30.301 [CONSOLE]
> 2016-10-29 16:44:30.302 execution.jsm: EnigmailExecution.execCmd:
> subprocess = '/usr/local/bin/gpg2'
> 2016-10-29 16:44:30.302 [CONSOLE] enigmail> /usr/local/bin/gpg2
> --charset utf-8 --display-charset utf-8 --use-agent --batch --no-tty
> --status-fd 2 --import --trustdb
> /Users/pbr/Library/Caches/TemporaryItems/enigmail_import/trustdb
> --no-default-keyring --keyring
> /Users/pbr/Library/Caches/TemporaryItems/enigmail_import/keyring
>
> Do you see any exception in the Thunderbird console?

Ah, good call, sorry i didn't look there first.  When i open the key
manager dialog box, i get a small warning that i think is irrelevant to
this concern [0].

Then when i try to do the import, i see the following error:

Timestamp: 10/30/2016 01:44:08 PM
Error: NS_ERROR_FILE_ALREADY_EXISTS: Component returned failure code: 
0x80520008 (NS_ERROR_FILE_ALREADY_EXISTS) [nsIFile.create]
Source File: resource://enigmail/files.jsm
Line: 263

That's createTempSubDir, presumably with dirName="enigmail_import".
Sure enough, i have $TMPDIR/enigmail_import already (probably leftovers
From a previous attempt that failed due to the arglist).

If i "mv $TMPDIR/enigmail_import{,.bak}" then try the import again, it
succeeds as expected. [1]

So: is it possible to use a dynamically-named temporary directory?
using $TMPDIR/enigmail_import seems prone to failure -- and for people
sharing a mode 1777 /tmp as $TMPDIR, it looks like one person could
block all other people on a given machine from doing imports.  (the same
is likely also true for "$TMPDIR/enig-imp" and "$TMPDIR/enig-exp").  On
a POSIX platform, i'd recommend mkstemp() -- but i don't know what the
equivalent is for enigmail's platform.

   --dkg

[0] The warning is:

Timestamp: 10/30/2016 01:43:25 PM
Warning: XUL box for a element contained an inline #text child, forcing all 
its children to be wrapped in a block.
Source File: chrome://enigmail/content/enigmailKeyManager.xul
Line: 0

I suspect this can be fixed with:

--- a/ui/content/enigmailKeyManager.xul
+++ b/ui/content/enigmailKeyManager.xul
@@ -454,8 +454,7 @@
 
 
 
-  
+   
 
   
 



[1] As another digression, after success, i get the following warning on
the console:

Timestamp: 10/30/2016 01:53:20 PM
Warning: Expected ':' but found ';'.  Declaration dropped.
Source File: chrome://enigmail/content/enigmailKeyImportInfo.xul
Line: 0, Column: 5
Source Code:
plain;white-space: pre
-^

I think this can be fixed with the following (based on similar elements
in ui/content/keyDetailsDlg.xul):

--- a/ui/content/enigmailKeyImportInfo.xul
+++ b/ui/content/enigmailKeyImportInfo.xul
@@ -31,7 +31,7 @@
 
   
 
-  
+  
 
   


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] [ENIGMAIL-1.9-BRANCH PATCH] keep options distinct

[Daniel Kahn Gillmor]

On Sat 2016-10-29 05:09:12 -0400, Patrick Brunschwig wrote:
> The problem is that there is no output on stderr, even though
> --status-fd 2 is specified. I added --no-verbose because "verbose"
> options in gpg.conf make gpg ignore --status-fd 2. Apparently there is
> something more in your gpg.conf file with the same result.

I think that the command that we're talking about is:

   /usr/bin/gpg --charset utf-8 --display-charset utf-8 --use-agent --batch 
--no-tty --status-fd 2 --no-verbose --list-packets

Is that right?

if so, when i run that with foo.asc on stdin, i don't see *anything* on
fd 2 anyway, even when run from a clean home directory with an empty
gpg.conf.  What are you expecting to see on the status-fd from
--list-packets?

  --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] [ENIGMAIL-1.9-BRANCH PATCH] keep options distinct

[Daniel Kahn Gillmor]

On Fri 2016-10-28 12:57:34 -0400, Patrick Brunschwig wrote:
> On 28.10.16 18:42, Daniel Kahn Gillmor wrote:
>> On Fri 2016-10-28 12:10:34 -0400, Ludwig Hügelschäfer wrote:
>> 
>>> Just tested: enigmail-1.9-branch imports a key from file as well as
>>> master here.
>> 
>> What version of GnuPG were you using to test?  I'm using 2.1.15-8 (on
>> debian testing/unstable).
>
> Importing works fine for me with GnuPG 2.1.15 (on Mac OS X).
>
> Can you send me the debug log file?

Below is the section of the debug log that appears when doing "Key
Manager Dialog | File | Import Keys from File…".

The file i pointed it at is the same foo.asc as earlier in the thread.

let me know if you need anything else.

   --dkg


--
2016-10-28 14:34:59.428 [DEBUG] enigmailCommon.jsm: filePicker: true
2016-10-28 14:35:21.652 [DEBUG] enigmailMessengerOverlay.js: 
updateOptionsDisplay: 
2016-10-28 14:35:21.652 [DEBUG] funcs.jsm: collapseAdvanced:
2016-10-28 14:35:24.246 [DEBUG] enigmailCommon.js: EnigInitCommon: 
id=enigmailKeyManager
2016-10-28 14:35:24.267 [DEBUG] enigmailKeyManager.js: enigmailKeyManagerLoad
2016-10-28 14:35:24.269 [DEBUG] enigmailCommon.jsm: dispatchEvent f=loadkeyList
2016-10-28 14:35:24.370 [DEBUG] enigmailCommon.jsm: dispatchEvent got notified
2016-10-28 14:35:24.370 [DEBUG] enigmailKeyManager.js: loadkeyList
2016-10-28 14:35:24.370 [DEBUG] enigmailKeyManager.js: enigmailBuildList
2016-10-28 14:35:31.226 [DEBUG] enigmailCommon.jsm: filePicker: false
2016-10-28 14:35:35.464 execution.jsm: EnigmailExecution.execCmd: subprocess = 
'/usr/bin/gpg'
2016-10-28 14:35:35.464 [CONSOLE] enigmail> /usr/bin/gpg --charset utf-8 
--display-charset utf-8 --use-agent --batch --no-tty --status-fd 2 --no-verbose 
--list-packets
2016-10-28 14:35:35.522 [DEBUG]   enigmail> DONE
2016-10-28 14:35:35.522 [DEBUG] execution.jsm: EnigmailExecution.execCmd: 
exitCode = 0
2016-10-28 14:35:35.522 [DEBUG] execution.jsm: EnigmailExecution.execCmd: 
errOutput = 
2016-10-28 14:35:35.522 [DEBUG] errorHandling.jsm: parseErrorOutputWith: status 
message: 

2016-10-28 14:35:35.523 [DEBUG] system.jsm: determineSystemCharset
2016-10-28 14:35:35.523 [DEBUG] system.jsm: determineSystemCharset: 
charset='iso-8859-1'
2016-10-28 14:35:35.523 [DEBUG] errorHandling.jsm: parseErrorOutputWith: 
statusFlags = 
2016-10-28 14:35:35.523 [DEBUG] errorHandling.jsm: parseErrorOutputWith: return 
with c.errorMsg = 
2016-10-28 14:35:35.523 [DEBUG] execution.jsm: EnigmailExecution.fixExitCode: 
agentType: gpg exitCode: 0 statusFlags undefined
2016-10-28 14:35:35.523 [CONSOLE] 
2016-10-28 14:35:41.812 [DEBUG] enigmailMessengerOverlay.js: 
updateOptionsDisplay: 
2016-10-28 14:35:41.813 [DEBUG] funcs.jsm: collapseAdvanced:
2016-10-28 14:35:43.644 [DEBUG] enigmailMessengerOverlay.js: 
updateOptionsDisplay: 
2016-10-28 14:35:43.644 [DEBUG] funcs.jsm: collapseAdvanced:
2016-10-28 14:35:44.456 [DEBUG] enigmailHelp.js: enigLoadPage
2016-10-28 14:35:44.456 [DEBUG] enigmailCommon.jsm: getFrame: name=contentFrame
--


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] [ENIGMAIL-1.9-BRANCH PATCH] keep options distinct

[Daniel Kahn Gillmor]

On Fri 2016-10-28 12:10:34 -0400, Ludwig Hügelschäfer wrote:

> Just tested: enigmail-1.9-branch imports a key from file as well as
> master here.

What version of GnuPG were you using to test?  I'm using 2.1.15-8 (on
debian testing/unstable).

   --dkg

___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] [ENIGMAIL-1.9-BRANCH PATCH] keep options distinct

[Daniel Kahn Gillmor]

On Thu 2016-10-27 12:13:56 -0400, Daniel Kahn Gillmor wrote:
> args is a list of distinct options, not a comma-separated string.

Even with this patch applied, i find that running enigmail-1.9-branch, i
can't import a key from a file.

Take as an example the attached file.

From the key management dialog box, i choose "File | Import Keys from
File", and then point the chooser at foo.asc.

The debug log shows:

 2016-10-27 12:11:47.275 [DEBUG] enigmailCommon.jsm: filePicker: false
 2016-10-27 12:11:49.589 execution.jsm: EnigmailExecution.execCmd: 
subprocess = '/usr/bin/gpg'
 2016-10-27 12:11:49.589 [CONSOLE] enigmail> /usr/bin/gpg --charset utf-8 
--display-charset utf-8 --use-agent --batch --no-tty --status-fd 2 --no-verbose 
--list-packets
 2016-10-27 12:11:49.638 [DEBUG]   enigmail> DONE
 2016-10-27 12:11:49.638 [DEBUG] execution.jsm: EnigmailExecution.execCmd: 
exitCode = 0
 2016-10-27 12:11:49.638 [DEBUG] execution.jsm: EnigmailExecution.execCmd: 
errOutput = 
 2016-10-27 12:11:49.638 [DEBUG] errorHandling.jsm: parseErrorOutputWith: 
status message: 

 2016-10-27 12:11:49.639 [DEBUG] system.jsm: determineSystemCharset
 2016-10-27 12:11:49.639 [DEBUG] system.jsm: determineSystemCharset: 
charset='iso-8859-1'
 2016-10-27 12:11:49.639 [DEBUG] errorHandling.jsm: parseErrorOutputWith: 
statusFlags = 
 2016-10-27 12:11:49.639 [DEBUG] errorHandling.jsm: parseErrorOutputWith: 
return with c.errorMsg = 
 2016-10-27 12:11:49.639 [DEBUG] execution.jsm: 
EnigmailExecution.fixExitCode: agentType: gpg exitCode: 0 statusFlags undefined
 2016-10-27 12:11:49.639 [CONSOLE] 

But then nothing actually gets imported, and no error messages appear.

Any suggestions for what to debug next?

--dkg

-BEGIN PGP PUBLIC KEY BLOCK-

mQINBFNNZNgBEAC1NWTQSUQLhW+QpaDc5I/9mSaRpxVcwEjGsEvCS+BzF7PhovG3
GCt7MQ6WzIEMOWD4aAhSaPji5NZgM/cbJku1n4Nx6x/q+P1agfYingJoVAgn6LNh
iMPzDFZd0S6nmYj/D22SGZY7ot/01q016s3PKyspkEO93R846tSaFl+Qnntq7UoZ
Z/G6pZ18GHGfva1riQ9i5yYbiKfNPvDeVsp0YOwmjtl1BL8WwtOLgEF90VX0djNR
OCuuj3q5ccf3ZEfN2I0B3gDjxlun0wgRysBNgp25trvd7Ejlx5cYi7WgT6/SAzmB
7ZfYspCMXusFPOG6W4Ggi8cUTWVLO8vFR20BKukB9xYFo1RqsuZgEKxwuRcsjlGQ
OtHiJnrB1U5jOduDQ+Lcn5Fncer0vxk0UrjX8Sy5SksR8pSZNokIfJuheqRykqUa
QhTfMDqtweUtVsSuE0mnFSxFyX0+IDkVwnTqpP0ub6BN9naAdTopxN1U3yN3stzB
xCQdo5G33Unf0zSPAwFUzYkvHCdwOtaYq3XBvZ1K/vghKYSsZj47xew5oyU50Jht
VMfj9/ft/E1l1htViPPOFOw9J4bE8sU0r/COFEmxCbAEs0HrYd926dmaOZfWu2Pw
AFskpH8ISJ+zDhfEcPuqiX/qACUzx2Zafi5fkj443UWfWh4GiVLODOvD3QARAQAB
tEVEZWJpYW4gVGVzdGluZyBDRHMgQXV0b21hdGljIFNpZ25pbmcgS2V5IDxkZWJp
YW4tY2RAbGlzdHMuZGViaWFuLm9yZz6JAhwEEAEIAAYFAlNNZXoACgkQWHl5VzRC
aE7O3A/8Dn/Oqu4mFDEZSfBmotPPNQf9e5+Uj4VpYoFYdTDp9yjf/iTnc2YS9kjD
1VkUbmOMAvABp8JnZY0P+hnF5LQhz7Jk4nT+mPpw/Rzsz/iOnXvrLDbPNs+5FYq5
/01fcC4sen5Je1nrfq950B57u7M5t4jdGvjSKA3s73Nw43/RtiCzgmdOQCgMR+Z1
9SbznYAZenSQ857Kd9KPIrPICV/3DOeegOA3+8wzPMnPe0YxiU5WcSYZp8IUly/I
LW35BQCVu2nZs7uT2ohDpMs4vBKWXcb6rUR+yZ9uRphPk8d3yjtPECbwWseI8o/N
6ALRh6aFro7DCfRH6zOwgCt3XMimTKGpbsRNNc/IhZykerkQCHOmEhs0ilTZaYhi
kxzFCUMBzU4Z6gtzZ8hrsnIdMB3jIn1DB0G0dWNAtjy6K/fibRkctEAVUPqLAXuc
HULmOAV2lv0FfkwAN7h07JawD1KfifHIZuAvLDGWAMx4rQmmaGUVlWDu27sD+Wx/
XbjpoyvGYR735achgIo9llJ5P06VcjvITwMAiAo2v+8+8fYjbWD5bS6VylT99DmM
Kb3JSv3o90/iAvmxNsWUZucMvt8DeN08/myST1nPzLJ1R2g2V92nk8OoqVaLD2lO
VBOL119pJpuI5ZdHQmu7Vwpkoqmi0ijxdrl/kTkTxa683Q+nf++JAhwEEAEIAAYF
AlNNZcgACgkQ2ofoDWKUvpvkXw/8CpchAxmNGAIKimYuxUo0i84F/qNbz/Srn+X1
IklU0aB1k46Ea/tkc6wREEZKYq/0v1TukCK6Ij0dqvyv3Ez1CB0zqEha8yp4/k5i
y1VhhWLEImonjTJNJLSUOsl5zDj7ZyhIRoBD0p4M7tD3haCfAw5o6I/XoKYEEGxN
9NckCPxNdp6OKhV8m5KbfkyTH6tN6S0AstXQIk6DO8lZ83W+rNBVcJ7oqaD8z/RY
MMgOIdeKrgYYOL4exFz8Hv1lH7AsYPRoJj8iQG9+/WrG2U1MsOq+lYRE6fIjSRqq
ByABp5fFIPFqCMFhwqbBBxQNyntKGwAHCRn3Q+kET7eEtOe52fiYNXuUwJtk/np3
SVXNERn72znSrP5hDXdmioB/zfMj9SMf2XRqPlGpEHcpRsF5vdrvPBALkIC7utRr
iiUS8BMZOu7kjf/yx9D0Ifoo31GQRkC0DEdddpZNSRAaiYNSvkMW6705KRfNtTcv
M4Ln4KslToFgGQtObBFeZlOW+nV8Aq2mzaXZ66WMiA2UTL+qhyiAuwtlOkWDOHO9
YNKJt2eGSUtRZ355mE35aVcJHMsmuZLmh2g0pjmhw6EzJHCKVICvH2Z1TXtcxV0X
gQPV0VJZBR3qIxil6HWqJ40NefRqGesBBu2VEVV9vSBl9bYYCTNnecmnKsvRmbs2
8vCUcB+JAhwEEAEKAAYFAlVbO10ACgkQW4IagTuUp8TkFw//RydxUMYgiL+0joNV
SKa8jkeHgssFx9uxH0e+p0ZAovzoo1pqEI8Msyc8nULvETNRg4Nl83vSkeo7m+4K
Xpr2ysu7jxRygA50mnH/fvxuJX5ZsZDycjAIH5os2ffziBwS4EYmTAHVn2J5nYfD
3FJUnhgYelwEI1RyVeouMRne2kxaqPPg9JT+rGjIDeLpBoQjsriTkzFQETl4D5QP
r30DLlb5dpyN5u5ufTGSVA9Gc1B+4ilvYszYeKVcAFbVsBsszRR/b90J5SRFh2X7
+0QhAkKc5XIzEiJwWEzRfLtHUHk7GXAmwpejSKosW56N0Ut9ISU8Zroai5cv5xF3
rgtiO/sD+jvW4aU1ExhITmhhzZMT3eT4Sm4FuqDuouawxh/Zfbmx6+YO0ZFv44jS
dyryzlNEHncgn6Ut0KYOxVsq43N7WphLJqXRWOILcSqZop0Y9kfrIEJIVpR/HWdZ
QzIFWJ8JMhLpOdO+rUzy0bx9AbuDHZkP0JOgERo5M6nnljozrqWPFf/PePKQkwIz
7iHk39ZipSFt4ryKkddTbrf9QGjRCmtm/xpOLE4sRvZHD4Xiiin9Ljq9xRTg80oN
QfZfqdjWrWxSByjw34238hc7vCBS4F1VOjRlyVULHYLs34HG6/qWvW2zkw4OeH2N
YvzqeHViTKKC78lPj6tvC+h5b+uJAjgEEwEIACIFAlNNZNgCGwMGCwkIBwMCBhUI
AgkKCwQWAgMBAh4BAheAAAoJEEJGj0AJ6orDN/YQAIq5QtT2W9UX5F8mebzSkZIx
VDsGMQ3NihtGW9qPCFgh3XW302yGcqWzYW/mtkSSm88+B

[Enigmail] [ENIGMAIL-1.9-BRANCH PATCH] keep options distinct

[Daniel Kahn Gillmor]

args is a list of distinct options, not a comma-separated string.
---
 package/key.jsm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/key.jsm b/package/key.jsm
index ecdbdae..ab4b739 100644
--- a/package/key.jsm
+++ b/package/key.jsm
@@ -195,7 +195,7 @@ var EnigmailKey = {
*- packetStr - String: the packet list as received from GnuPG
*/
   getKeyFileType: function(keyBlockStr) {
-let args = EnigmailGpg.getStandardArgs(true).concat(["--no-verbose, 
--list-packets"]);
+let args = EnigmailGpg.getStandardArgs(true).concat(["--no-verbose", 
"--list-packets"]);
 const exitCodeObj = {};
 const statusMsgObj = {};
 const errorMsgObj = {};
-- 
2.9.3


___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] clearsigned messages showing up blank

[Daniel Kahn Gillmor]

hey enigmail folks--

i'm running enigmail 1.9.5-2 on debian with icedove 1:45.4.0-1

I just received a message structured like this:

A└┬╴multipart/signed 26760 bytes
B ├┬╴multipart/mixed 1689 bytes
C │└─╴text/plain 1115 bytes
D └─╴application/pgp-signature attachment [signature.asc] 1188 bytes

Part C is (probably unnecessarily) base64-encoded, as it contains only
ascii text.

It looks like it has also been sent by thunderbird, but it has passed
through at least one exchange server, if i'm reading the headers
directly.

enigmail shows this message as a completely blank body with no enigmail
security indicators.

when i inspect the raw message and base64-decode it myself, it clearly
has a body with text in it.  Nothing is printed to stderr when viewing,
and when i try to reply, the reply body is also blank (and still nothing
is printed by icedove to stderr).

Any ideas what i can do to further debug?  Can anyone else replicate
this?

--dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Debian Jessie only offers Enigmail 1.8.2, is it safe to install 1.9.5 from Sid?

[Daniel Kahn Gillmor]

On Mon 2016-09-12 12:41:41 +0200, Vatta wrote:
> Am 11.09.2016 um 17:50 schrieb Patrick Brunschwig:
>> It depends on the Thunderbird version. If you are using Thunderbird 38,
>> then you better stick with Enigmail 1.8.2. If you are using Thunderbird
>> 45 or newer, you can upgrade to Enigmail 1.9.5.
>
> I'm using TB 45.3 from the Debian repo.

hm, maybe we should try to upgrade enigmail in jessie to 1.9.5 to track
thunderbird's changes.  I can provide a backport easily, and we could
talk to the release team about an update within the next point-release.

Patrick, Willi, any thoughts about this course of action?

  --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Mac pinentry Problem

[Daniel Kahn Gillmor]

On Wed 2016-09-07 20:47:59 +0200, Tom Ritter wrote:
> When I choose an encrypted email in Thunderbird, it displays a blank
> preview page, no prompt for passphrase. When I cache my password by
> using gpg on the command line, then it decrypts.
>
> I am using pinentry-mac from homebrew and symlinked pinentry to it. My
> gpg-agent.conf file includes
> pinentry-program /usr/local/bin/pinentry-mac

Can you try including the following two lines in ~/.gnupg/gpg-agent.conf?

debug-pinentry
debug 1024

and then repeat the experiment?  It'd be useful to see what the pinentry
is actively doing...

--dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Mac pinentry Problem

[Daniel Kahn Gillmor]

On Wed 2016-09-07 20:47:59 +0200, Tom Ritter wrote:
> Strangely, all the items I replaced with  etc are not in my
> keyring.  Checked by doing gpg --fingerprint --fingerprint --list-keys
> | grep  (with the first 4 octets of each key).

are you sure about that?  pinentry refers to a key by its "keygrip",
which is distinct from the OpenPGP fingerprint.  iirc, the keygrip
calculated over just the raw public key info, while the OpenPGP
fingerprint includes some additional OpenPGP-specific boilerplate as
well as the key creation time.

If you try --with-keygrip do the values make any more sense?

 --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] [PATCH] use modern keyservers as examples

[Daniel Kahn Gillmor]

default to using the keyserver pool as an example, rather than
encouraging the use of proprietary or defunct keyservers.
---
 lang/bg/enigmail.dtd | 2 +-
 lang/ca/enigmail.dtd | 2 +-
 lang/cs/enigmail.dtd | 2 +-
 lang/el/enigmail.dtd | 2 +-
 lang/es-AR/enigmail.dtd  | 2 +-
 lang/es-ES/enigmail.dtd  | 2 +-
 lang/eu/enigmail.dtd | 2 +-
 lang/fi/enigmail.dtd | 2 +-
 lang/fr/enigmail.dtd | 2 +-
 lang/gd/enigmail.dtd | 2 +-
 lang/gl/enigmail.dtd | 2 +-
 lang/hr/enigmail.dtd | 2 +-
 lang/hu/enigmail.dtd | 2 +-
 lang/it/enigmail.dtd | 2 +-
 lang/ko/enigmail.dtd | 2 +-
 lang/lt/enigmail.dtd | 2 +-
 lang/nb-NO/enigmail.dtd  | 2 +-
 lang/nl/enigmail.dtd | 2 +-
 lang/pl/enigmail.dtd | 2 +-
 lang/pt-BR/enigmail.dtd  | 2 +-
 lang/pt-PT/enigmail.dtd  | 2 +-
 lang/ru/enigmail.dtd | 2 +-
 lang/sk/enigmail.dtd | 2 +-
 lang/sl/enigmail.dtd | 2 +-
 lang/sq/enigmail.dtd | 2 +-
 lang/sv-SE/enigmail.dtd  | 2 +-
 lang/tr/enigmail.dtd | 2 +-
 lang/vi/enigmail.dtd | 2 +-
 lang/zh-CN/enigmail.dtd  | 2 +-
 ui/locale/en-US/enigmail.dtd | 2 +-
 30 files changed, 30 insertions(+), 30 deletions(-)

diff --git a/lang/bg/enigmail.dtd b/lang/bg/enigmail.dtd
index 402b8d2..5e930fa 100644
--- a/lang/bg/enigmail.dtd
+++ b/lang/bg/enigmail.dtd
@@ -47,7 +47,7 @@
 
 
 
-ldap://certserver.pgp.com;>
+
 
 
 
diff --git a/lang/ca/enigmail.dtd b/lang/ca/enigmail.dtd
index 59cc7db..dfd6d19 100644
--- a/lang/ca/enigmail.dtd
+++ b/lang/ca/enigmail.dtd
@@ -47,7 +47,7 @@
 
 
 
-ldap://certserver.pgp.com;>
+
 
 
 
diff --git a/lang/cs/enigmail.dtd b/lang/cs/enigmail.dtd
index bca5669..e3bbd96 100644
--- a/lang/cs/enigmail.dtd
+++ b/lang/cs/enigmail.dtd
@@ -47,7 +47,7 @@
 
 
 
-ldap://certserver.pgp.com;>
+
 
 
 
diff --git a/lang/el/enigmail.dtd b/lang/el/enigmail.dtd
index 6d8d6f6..1ec225a 100644
--- a/lang/el/enigmail.dtd
+++ b/lang/el/enigmail.dtd
@@ -47,7 +47,7 @@
 
 
 
-ldap://certserver.pgp.com;>
+
 
 
 
diff --git a/lang/es-AR/enigmail.dtd b/lang/es-AR/enigmail.dtd
index 856504b..3f1059d 100644
--- a/lang/es-AR/enigmail.dtd
+++ b/lang/es-AR/enigmail.dtd
@@ -52,7 +52,7 @@
 
 
 
-ldap://certserver.pgp.com;>
+
 
 
 
diff --git a/lang/es-ES/enigmail.dtd b/lang/es-ES/enigmail.dtd
index 186f96c..f556dc4 100644
--- a/lang/es-ES/enigmail.dtd
+++ b/lang/es-ES/enigmail.dtd
@@ -49,7 +49,7 @@
 
 
 
-ldap://certserver.pgp.com;>
+
 
 
 
diff --git a/lang/eu/enigmail.dtd b/lang/eu/enigmail.dtd
index 4c0d733..278378d 100644
--- a/lang/eu/enigmail.dtd
+++ b/lang/eu/enigmail.dtd
@@ -52,7 +52,7 @@
 
 
 
-ldap://certserver.pgp.com;>
+
 
 
 
diff --git a/lang/fi/enigmail.dtd b/lang/fi/enigmail.dtd
index a44f6df..e17a90c 100644
--- a/lang/fi/enigmail.dtd
+++ b/lang/fi/enigmail.dtd
@@ -49,7 +49,7 @@
 
 
 
-ldap://certserver.pgp.com;>
+
 
 
 
diff --git a/lang/fr/enigmail.dtd b/lang/fr/enigmail.dtd
index 2830678..5e80e9d 100644
--- a/lang/fr/enigmail.dtd
+++ b/lang/fr/enigmail.dtd
@@ -55,7 +55,7 @@
 
 
 
-ldap://certserver.pgp.com;>
+
 
 
 
diff --git a/lang/gd/enigmail.dtd b/lang/gd/enigmail.dtd
index 108e416..c5d9c90 100644
--- a/lang/gd/enigmail.dtd
+++ b/lang/gd/enigmail.dtd
@@ -55,7 +55,7 @@
 
 
 
-ldap://certserver.pgp.com;>
+
 
 
 
diff --git a/lang/gl/enigmail.dtd b/lang/gl/enigmail.dtd
index 14ccd47..c5cf6df 100644
--- a/lang/gl/enigmail.dtd
+++ b/lang/gl/enigmail.dtd
@@ -55,7 +55,7 @@
 
 
 
-ldap://certserver.pgp.com;>
+
 
 
 
diff --git a/lang/hr/enigmail.dtd b/lang/hr/enigmail.dtd
index 328ddec..9231be3 100644
--- a/lang/hr/enigmail.dtd
+++ b/lang/hr/enigmail.dtd
@@ -55,7 +55,7 @@
 
 
 
-ldap://certserver.pgp.com;>
+
 
 
 
diff --git a/lang/hu/enigmail.dtd b/lang/hu/enigmail.dtd
index c1b348f..eda2dd4 100644
--- a/lang/hu/enigmail.dtd
+++ b/lang/hu/enigmail.dtd
@@ -55,7 +55,7 @@
 
 
 
-ldap://certserver.pgp.com;>
+
 
 
 
diff --git a/lang/it/enigmail.dtd b/lang/it/enigmail.dtd
index 2c30699..ff0aa6b 100644
--- a/lang/it/enigmail.dtd
+++ b/lang/it/enigmail.dtd
@@ -55,7 +55,7 @@
 
 
 
-ldap://certserver.pgp.com;>
+
 
 
 
diff --git a/lang/ko/enigmail.dtd b/lang/ko/enigmail.dtd
index b16b6b4..54a9b87 100644
--- a/lang/ko/enigmail.dtd
+++ b/lang/ko/enigmail.dtd
@@ -49,7 +49,7 @@
 
 
 
-ldap://certserver.pgp.com;>
+
 
 
 
diff --git a/lang/lt/enigmail.dtd b/lang/lt/enigmail.dtd
index 525fa3e..10c6d14 100644
--- a/lang/lt/enigmail.dtd
+++ b/lang/lt/enigmail.dtd
@@ -49,7 +49,7 @@
 
 
 
-ldap://certserver.pgp.com;>
+
 
 
 
diff --git a/lang/nb-NO/enigmail.dtd b/lang/nb-NO/enigmail.dtd
index 998b4f0..1d04957 100644
--- a/lang/nb-NO/enigmail.dtd
+++ b/lang/nb-NO/enigmail.dtd
@@ -55,7 +55,7 @@
 
 
 
-ldap://certserver.pgp.com;>
+
 
 
 
diff --git a/lang/nl/enigmail.dtd b/lang/nl/enigmail.dtd
index 99dfea1..310e9f6 100644
--- a/lang/nl/enigmail.dtd
+++ b/lang/nl/enigmail.dtd
@@ -55,7 +55,7 @@
 
 
 
-ldap://certserver.pgp.com;>
+
 
 
 
diff --git a/lang/pl/enigmail.dtd 

Re: [Enigmail] Have to killall and relaunch gpg-agent after every reboot..

[Daniel Kahn Gillmor]

On Thu 2016-09-01 16:28:44 -0400, Bitcoin Admin wrote:
> Yes, that 'other user' was me. And a fresh gnupg install solved the
> dilemma, just imported the keyring and trustdb

if you could send me a diff between your old gpg.conf and gpg-agent.conf
(the ones that don't work) and the new ones (that do work), i'd be
interested in seeing it.

If there's sensitive info in it, feel free to redact.

> I had to remove one other file pubring.kbx, as it conflicts with the
> pubring.gpg

If you're using the modern branch of gnupg, you're better off moving
pubring.gpg out of the way and relying solely on pubring.kbx, rather
than the other way around.

You might try:

mv ~/.gnupg/pubring.gpg ~/.gnupg/pubring.gpg.old
gpg --import-options import-local --import < ~/.gnupg/pubring.gpg.old

on debian systems where gpg is version 2.1 or higher, you might also try
"migrate-pubring-from-classic-gpg".

Regards,

--dkg

___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Problems with sorting messages encrypted with Memory Hole standard

[Daniel Kahn Gillmor]

On Tue 2016-08-09 02:11:47 -0400, Patrick Brunschwig wrote:
> The implementation in the next major version of Enigmail will no longer
> encrypt the "References" header automatically (you can still enable it
> in a preference). I know this leaks more data than ultimately desired,
> but it's still better than nothing.

To be clear: it should still encrypt the references: header, but i think
you're saying that it will not strip or replace the references header
outside of the encryptions.  right?

--dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] [ANN] Enigmail v1.9.4 available

[Daniel Kahn Gillmor]

Hi Patrick--

On Mon 2016-07-04 12:05:13 -0400, Patrick Brunschwig wrote:
> I'm happy to announce the availability of Enigmail v1.9.4 for
> Thunderbird versions 38, 45 and newer, and SeaMonkey 2.35 and newer.

I'd already incorporated most of these fixes into debian's 1.9.3-2, but
i've just re-rolled 1.9.4-1 for debian, and it should be in debian
unstable later today.

thanks for the update!

  --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Unverified signatures and mailing lists

[Daniel Kahn Gillmor]

Hi Duncan--

On Wed 2016-06-22 19:39:51 -0400, Duncan Guthrie wrote:
> When I send messages to mailing lists, they have started to become
> 'unverified'. When I send the email and sign it, in my 'sent' folder
> the signature is good. However, when the mailing list receives it, the
> signature is unverified.
> Has anyone ever had similar problems, and if so, how do I fix it? I
> have begun to suspect that this may be due to the protocol being
> PGP/MIME, this producing a bad signature when processed by the mailing
> list software, so would using inline PGP be the way forward? I have
> tried to send this mail with inline PGP to see if this works, and
> composed the messages in plain-text format.

Your signature on this e-mail was using PGP/MIME, and it verified just
fine for me.  Note that the footer appended by the mailing list is *not*
included in the signature (regardless of whether using PGP/MIME or
inline signatures), so the entire message body is not itself verified;
just part of it.

Regards,

 --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Strange error msg

[Daniel Kahn Gillmor]

[ Please send a new e-mail when a new question, rather than replying to
  an existing e-mail and "hijacking" a previous thread. ]

On Wed 2016-06-01 17:06:14 -0400, David Vallier wrote:
> Today enigmail/gpg told me that a persons key wasn't compatible with my
> version of gpg (using gpg2) what gives with that?

Can you provide more details?

 * what version of gpg are you using?

 * what was the error message exactly?

 * what key specifically caused the problem (if you're ok with sharing
   that detail)?


   --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Rules for attaching public key

[Daniel Kahn Gillmor]

On Wed 2016-06-01 16:28:51 -0400, Ludwig Hügelschäfer wrote:
> On 01.06.16 19:52, Daniel Kahn Gillmor wrote:
>
>> I agree that keeping some state (or being able to infer state) about
>> whether your peer likely has your key would be a useful thing.  I'm not
>> sure what the right rules would be to make this relatively seamless and
>> not-confusing, though.
>
> One thing is clear: If the local installation has already received
> encrypted mails from this address, it is no longer necessary to send the
> own key again. Not sure how to implement this, this would require some
> sort of mini-addressbook.

Can we piggy-back enigmail's state on thunderbird's own addressbook?

Also, if the user's own certificate (or their encryption-capable subkey)
was due to expire, but they updated the expiration date (or issued a new
encryption-capable subkey), should they re-send their certificate to the
peer?

--dkg

___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Rules for attaching public key

[Daniel Kahn Gillmor]

On Wed 2016-06-01 13:46:28 -0400, Bob Henson wrote:
> On 01/06/2016 6:32 pm, Hakuch wrote:
>> are there any possibilities to create rules for public key attaching?
>> Currently, I send always my public key to everyone, even if I sent it
>> already 2000 times to a specific person.
>
> Why not just put your key number in your signature and let them get it
> from a keyserver if they want it?

 * some people don't want their keys on the keyservers unless they've
   been revoked.
 
 * not everyone has access to a keyserver (i've recently recieved mail
   from someone asking for my key by mail because at work they can't get
   through to the keyservers)

 * some people fetch their mail, disconnect, and read and respond to it
   while offline, so having the local key is handy.

I agree that keeping some state (or being able to infer state) about
whether your peer likely has your key would be a useful thing.  I'm not
sure what the right rules would be to make this relatively seamless and
not-confusing, though.

   --dkg

___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Enigmail Message Filters: Decrypt only

[Daniel Kahn Gillmor]

On Sat 2016-03-26 20:31:45 -0400, Robert J. Hansen wrote:
 
> The complete list of must-haves:
 [ ... ]
> This list of copy-if-exists works for GnuPG 1.4, 2.0, and 2.1.

Or, copy everything and then delete random_seed before trying to use
GnuPG :)

--dkg

___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Importing Sec keys to Enigmail

[Daniel Kahn Gillmor]

Hi Tiger--

On Fri 2016-03-11 19:17:25 -0500, tiger.rail...@nili.ca wrote:

> Have exported secret keys from APG on Android and attempted to import to
> Enigmail on Thunderbird. Though it seems like nothing was imported.

People on this list want to be helpful, but you haven't provided enough
information for anyone to help you.

can you tell us:

 * how did you export the secret keys from APG?

 * what does the exported file look like?  (e.g. how big is it, is it
   ascii-armored, does it start with -BEGIN PGP PRIVATE KEY BLOCK-
   or does it start with something else?  if you have pgpdump available,
   what does pgpdump say about the file?)

 * what version of enigmail and thunderbird you're using?

 * what steps you took to import the file in enigmail

 * what feedback (if anything) you got from enigmail after the import.


all the best,

--dkg

___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] [BUG] Character encoding mix-up when encrypting Inline.

[Daniel Kahn Gillmor]

On Wed 2016-03-02 04:27:28 -0500, Lachezar Dobrev wrote:
>   My outgoing e-mail is set to send in UTF-8.
>   The 'use default encoding' option has a common negative effect: there are
> numerous encodings that support Cyrillic, and not all mail agents (quite a
> few web-mail agents) support MBCS properly, hence the use of the original
> encoding that the mail was received with is very useful, and when trying to
> send a mail with content that does not match the encoding Thunderbird will
> ask to switch to an Unicode character encoding. The last part is somewhat
> hampered when using Enigmail, it seems that the character encoding
> detection happens after Engimail has performed the encryption.
>
>   My preferred solution to this issue (and other) is to send mail in MIME
> format, but I can not force that on other people.

While you can't force it on other people, you can elect to do it
yourself.  If you're sending or receiving text that uses anything other
than 7-bit clean US ASCII characters, character encodings and
inline-PGP-encryption are going to be an unresolvable issue. :(

PGP/MIME works because it explicitly embeds the character encoding of
the cleartext inside the protected MIME part, so it cannot get out of
sync the way that inline PGP does.

  --dkg

___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Using PGP-MIME vs inline PGP?

[Daniel Kahn Gillmor]

Hi there--

On Wed 2016-02-24 17:37:32 -0500, Datse Multimedia Information wrote:
> When I opened Thunderbird today I received a message about the use of
> PGP-MIME as the new "default setting".  The "old" recommednation was
> that inline PGP (at least for signed messages, though not nescesarily
> for messages which are encrypted) was more compatable.

That decision has been a contentious one for years, and the balance has
tipped in favor of well-structured PGP/MIME messages.

A (non-exhaustive) list of arguments against inline PGP signatures is
here:

  https://dkg.fifthhorseman.net/notes/inline-pgp-harmful/

It's probably not worth re-kindling a flamewar here about this topic.

> With an inline PGP message I see that the message is sent with a pretty
> standard text based message.

Most "standard" messages today are not just plain text, especially not
raw US-ASCII.  even the text/plain messages are often base64-encoded or
quoted-printable-encoded UTF-8.  But most messages today aren't just
text/plain, much as some of us wish they were: they're text/html, or
multipart/alternative, or they have attachments, etc.  PGP/MIME handles
all of those forms in a sensible fashion.

> The problem that I see is that with inline MIME, there is an increased
> risk of not being able to verify signatures which *should* be valid, or
> the rendering of the email to be impossible to decrypt.

When you say "inline MIME", i'm assuming you mean "inline PGP".

There are lots of ways to break signatures; inline PGP signatures can
(and are) easily broken by MTAs as well.  This is in the nature of
cryptographic signature schemes -- any byte added or removed anywhere in
the part can actually break the signature.

Regards,

 --dkg


signature.asc
Description: PGP signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net