So maybe there is also a display problem, as I saw 0:00 in Kleo. I have to recheck.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Nov 7 2017
Oct 30 2017
When receiving an S/MIME mail that is encrypted, the successful log looks like:
Comparing the gpgol.log files in the case of OpenPGP decryption (successful) and S/MIME decryption in send folder (failing).
Here is the link to the wald report by John Mrkva:
https://wald.intevation.org/forum/forum.php?thread_id=1785&forum_id=21&group_id=11
Oct 27 2017
Hi, thanks for the report.
Oct 26 2017
Yesterday I could reproduce that emails in the "send" folder cannot be decrypted anymore.
Oct 25 2017
This week I'm trying to make progress with this issue.
Oct 11 2017
Oct 10 2017
Still failing.
Oct 9 2017
Oct 5 2017
I agree that it is better to keep it in two directories.
(The potential advantages outweight the drawbacks.)
Sep 25 2017
Sep 20 2017
Sep 19 2017
Sep 18 2017
Sep 15 2017
Sep 5 2017
Sep 4 2017
@aheinecke thanks for your findings.
Sep 3 2017
Aug 30 2017
Aug 23 2017
Aug 18 2017
Aug 16 2017
Retested today: Works again. So I can confirm the resolution of this task.
Thanks @marcus !
Aug 15 2017
Aug 8 2017
Gathered information:
@marcus you've closed it while I was adding stuff. Where shall we document the way forward? In wiki.gnupg.org or https://dev.gnupg.org/w/ or in this task?
Note that we could switch the wiki.gnupg.org back to local authentification
(or any other authentification that moinmo.in provides, see https://moinmo.in/AuthMarket)
and continue using it.
Jul 4 2017
Yes, it is probably correct: the concept mockup was done a lot earlier. Whatever we have in master is most likely the current status.
Jun 30 2017
Some details of these tasks are outline in the internal concept, including mockups.
Hi,
on which platform? (You can probably compare it to a working version and see which libraries is uses there.)
Jun 13 2017
May 23 2017
May 16 2017
Mar 15 2017
I can confirm that I can login again.
@justus: Thanks for the quick fix!
Werner: Will you provide a new authentication methods for people participating
in the GnuPG communit?
What should we do until then?
The wiki is potentially interesting each day. It is probably easiest for the
users if you restore the old behaviour until a new authentication method for the
GnuPG-Community is available. Otherwise users must change their credentials two
times (First to the separate wiki authentication now and then to the new one
once it is available.)
What is the estimated roadmap for replacing roundup?
Feb 23 2017
Sep 19 2016
@werner, if I understand the description at
https://www.gnu.org/software/tar/manual/html_section/tar_68.html
then ustar would also be able to read "posix" archives.
Sep 15 2016
Can you create a new issue with the data "loss" part?
As for the default format:
I think we should use and propose a default format that is mostly compatible
over platforms (and robust in the future). tar "posix" seems to be
such a format. Am not sure how this evaluates for karchive or 7zip.
I'm unsure about the compatibility issues with using a higher filename-length
limit.
Sep 13 2016
Spoke to Werner, it is better to do ntbtls anyway.
Timeline is: this year, hopefully earlier.
For ntbtls also see: https://wiki.gnupg.org/NTBTLS
ntbtls is a development from Werner:
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=ntbtls.git;a=summary
What about using https://tls.mbed.org/? At least until ntbtls is mature?
Sep 12 2016
@werner, if you prefer ntbtls over gnutls, okay. Can you add a link to ntblts
and outline the next steps. We'd probably need tls support for the web key
directory as well, so this needs a solution.
Sep 5 2016
Jochen, can you please find out:
a) Does this still work on GNU/Linux?
b) Did this work with elder Gpg4win version? With binary search you
should find out qickley when this broke.
Aug 26 2016
Okay, if this transfers line endings because of the textmode read, it will
depend on the contents of the CRL in question. This explains why the defect was
not seen in earlier testing.
And pem does not work for this (I guess and tried on a GNU system).
It is okay that pem does not work, because this is a rarely used function I think.
Aug 1 2016
Jun 27 2016
Hi,
the 2.1.13 announcement has
"""
- gpg: Allow export of non-passphrase protected secret keys.
"""
(from https://lists.gnupg.org/pipermail/gnupg-announce/2016q2/000390.html)
so this defect may be fixed with 2.1.13 I guess, cool!
Probably only need a test to confirm?
Jun 15 2016
Hi,
without having checked it, I think that dirmngr should try ldapv3 first.
The 2.1 versions for sure. For the others, a fallback should be good enough.
(Would it help if I go digging into specs somewhat to back that up?)
Jun 13 2016
@aheincke an myself observed different behaviour on two ldap server versions
(openldap).
Our new openldap server fails for old dirmngr 1.1.0 Version: 1.1.0+r347-0kk2
and 2.1.11 and master.
Internall we can still access the old ldap server for testing purposes.
Next step see on the wire what the differences could be.
Jun 7 2016
Jun 1 2016
I can confirm one defect with 2.1.11:
The ability to export a secret key without passphrase available in gnupg2.0
is gone. My use case is to write a testcase that automatically imports the key.
Duplicate of T2324