On 27/07/2020 22:53, Ayoub Misherghi wrote:
> With API I mean something like GPGME.
It seems to me that including options in gpg.conf that GPGME does not
expect people to put there might throw it out of whack.
> 1) It is preferable to have "--batch" on command line even in
> unattended
On 27/07/2020 20:56, Ayoub Misherghi wrote:
> The same thing happens when I give the option --no-batch on the
> command line.
But that only passes --no-batch to gpg, not to gpg-agent. Werner said
you shouldn't put these options in your .conf-files. Please just include
--batch on the command line
On 27/07/2020 11:17, Werner Koch wrote:
> of the "batch" option. This option should in general not be used for
> gpg-agent.
Which, by the way, is documented well in the man page gpg-agent(1):
--batch
Don't invoke a pinentry or do any other thing requiring human
Hi,
On 27/07/2020 07:03, Ayoub Misherghi via Gnupg-users wrote:
> Will this scenario work?
Yes, as long as you also kill the daemons so they restart with the new
situation:
$ gpgconf --kill all
HTH,
Peter.
--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me
On 20/07/2020 20:25, Ayoub Misherghi via Gnupg-users wrote:
> gpg: decryption failed: No secret key
Are your gpg.conf and gpg-agent.conf (or let's just say any .conf-file
in your GnuPG home, ~/.gnupg) empty? Do you get a pinentry popup asking
for a passphrase?
Peter.
--
I use the GNU Privacy
On 12/07/2020 20:01, Ayoub Misherghi wrote:
> Can you please suggest some good tutorial and reference material
> preferably free (probably mutually exclusive requirements) that will
> bring me up to your level or close to it please.
No, I think the available documentation is lacking in quality.
On 12/07/2020 17:45, Ayoub Misherghi wrote:
> Sorry for going off list and messing everybody up. Now I disserve
> punishment.
Heh :-). It's just that if I reply off-list, it only helps you, but if
it is on-list, other people can find it in a search engine when they're
facing something similar.
Hi,
On 11/07/2020 19:58, Ayoub Misherghi wrote:
> ayoub@vboxpwfl:~/sentry/trunk$ cat ~/.gnupg/gpg.conf
> batch
> pinentry-mode loopback
Ah yes. Those two options have no place in your gpg.conf. They are
options that you might want to specify as part of the command line on
occasion, but unless
Hi!
On 10/07/2020 23:47, Ayoub Misherghi via Gnupg-users wrote:
> ayoub@vboxpwfl:~/testdir$ gpg --list-secret-keys
Could you do
$ gpg --with-subkey-fingerprint --list-secret-keys
and
$ gpg --version
please?
And do you get a popup asking for your passphrase or is what you post
all the
On 29/06/2020 18:38, Fourhundred Thecat wrote:
> I don't have gpg-agent installed, on this particular server, where I
> need to decrypt one file.
You could try installing sequioa-pgp[1], an alternative but also libre
OpenPGP implementation (still in its infancy). It requires a Rust build
Hi,
On 31/05/2020 10:01, Patrick Brunschwig wrote:
> The only "problem" might be that you have different keys on different
> key rings. But this is not necessarily a problem - you use different
> keys for different purposes and you can import and export the keys
> between the tools if needed.
Hi,
On 28/05/2020 06:20, halfdog wrote:
> Using a signing key per source seems to be impractical here too as it
> would also require to transfer the whole file beforehand for signature
> verification.
What about solving your entire use-case with an explicit two-step
process:
There's an
On 25/05/2020 09:47, Michał Górny wrote:
> ...and that's really a good thing they can do that instead of choosing
> a more painful way of getting your fingerprints.
How is that an advantage compared to passphrases? As soon as someone
threatens to go all XKCD 538 on you[1], just give them your
On 24/05/2020 21:39, Mark wrote:
> I know there are other options maybe even some that use
> biometrics to decrypt the database.
I am very wary of biometrics for authentication purposes. There are so
many examples where the vendor assured us it was working really well,
and researchers easily
On 24/05/2020 19:11, Mark wrote:
> I think if all the important files are stored in an encrypted
> container, they should be pretty secure.
Just watch out for the catch-22 of "I lost my hard drive, let me restore
from that encrypted container. Hmmm, my only backup of my private key is
inside a
On 24/05/2020 18:03, Peter Lebbing wrote:
>> % gpg -o public-keys.gpg --export
Oh! That is perhaps not good enough :-). You need
$ gpg --export-options export-local-sigs -o public-keys.gpg --export
so you don't lose any non-exportable signatures. There's also
--export-options backup,
Hi,
On 24/05/2020 16:05, Felix Finch wrote:
> Out of curiosity ... how safe are these files as is, assuming the
> private key file has a good strong passphrase?
The safety of the private key purely depends on the strength of the
passphrase. Note that backups will have the passphrase that was set
On 24/05/2020 14:52, Damien Goutte-Gattat via Gnupg-users wrote:
> No, it’s not.
Absolutely not ;-)
> For the private and public keys however, instead of saving the files
> directly I’d recommend exporting them from GnuPG:
>
> % gpg -o private-keys.gpg --export-secret-keys
> % gpg -o
Another idea would be to deliberately destroy the encrypted primary key
material you upload to ProtonMail. I'd suggest setting the capabilities
of the primary key to just Certify, not Sign. It could very well be that
ProtonMail never tries to decrypt the encrypted primary private key
then, because
Werner recently mentioned an undocumented command for this.[1]
On 27/08/2019 11:30, Werner Koch via Gnupg-users wrote:
> You can extra the signature from the encrypted+signed data:
>
> gpg --unwrap -d -o SIG
> and then run
>
> gpgv -o SIGNEDFILE SIG && echo verified!
>
> --unwrap is not
On 17/09/2019 18:59, Stefan Claas via Gnupg-users wrote:
> I assume that in order to decrypt a message the secret key data must be
> unlocked and loaded for a very short time into the computers RAM, in order
> to perform the decryption, or am I wrong with my assumption?
OpenPGP messages encrypted
Hello Stefan,
On 01/09/2019 14:14, Stefan Claas via Gnupg-users wrote:
> Also interesting.
>
> https://eprint.iacr.org/2018/1121.pdf
If you post URL's to this mailing list, could you please provide a short
description of what can be found at the URL? This prevents the situation
that people
On 28/08/2019 12:07, Peter Lebbing wrote:
> Whether a compromise is game over depends on your scenario.
Sorry, I meant, it depends on your definition of "game over", definitely
*not* on the scenario.
I think it is perfectly acceptable to say "compromise = game over&qu
On 26/08/2019 01:26, Farhan Khan via Gnupg-users wrote:
> I use gnupg to sign my git commits, but after a few hours of use I
> have to restart gpg-agent. Before doing so, what I presume is
> gpg-agent asks me to re-enter my password on a random terminal (but it
> seems to drop characters and never
On 28/08/2019 00:41, Chris Narkiewicz via Gnupg-users wrote:
> This is not true. Many crypto systems are designed to perform damage
> control and recovery in such cases.
Damage control in the case of GnuPG would be using a smartcard: while
you are using the smartcard, so can the attacker, but
On 27/08/2019 21:50, Stefan Claas via Gnupg-users wrote:
> But what would be, when using computers at work or public places, then
> the best strategy for using OpenPGP, without carrying a Notebook or
> smartphone?
If a computer is compromised, this is game over for cryptography. Full
stop.
>
On 20/08/2019 19:46, vedaal via Gnupg-users wrote:
> Try This:
>
> [1] Open a new terminal command prompt window
> [2] Type gpg -a --export-secret-key keyname
I think ilf is quite correct that you need to enter your passphrase to
do an export from the agent-managed store in private-keys-v1.d.
Hi MFPA,
> Would the attack work by just concatenating lots of identical
> signature packets onto a copy of the target key and sending the result
> to the keyserver?
I have no knowledge of the workings of the keyservers. But my guess is
that they would all be coalesced into the single signature
Hello,
> ni@quark:~/.ssh$ ps aux | grep 22009
> ni7740 0.0 0.0 6076 892 pts/6S+ 11:21 0:00 grep
> 22009
> ni 22009 2.0 0.2 89404 78536 ?RL 02:51 10:30 gpg
> --batch --no-sk-comments --status-fd 104 --no-tty --charset utf8
> --enable-progress-filter
By the way, I keep intending to put this as a PS on a proper mail, but I
always forget.
All my mails to Rob keep bouncing. The first bounce was June 30th. I'm
not including the bounce message here on the off chance that there is
something non-public about Robs mail infrastructure :-). So Rob can
On 15/08/2019 08:50, Robert J. Hansen wrote:
> Additionally, the bad guys can create new malicious certificates faster
> than the keyserver network can blacklist.
Plus, the attacker could just create a signature that looks likely to be
real (self-sig or existing third-party sig seems a good
On 14/08/2019 12:29, Vincent Breitmoser wrote:
>> The algorithm is designed to withstand very well funded actors,
>> oppressive regimes were what the designers were thinking of.
>
> We are talking about a sand castle here that was kicked down by a kid. It's
> a bit bizarre to claim that it was
On 14/08/2019 12:09, Andrew Gallagher wrote:
> Indeed, but that condition is fundamentally incompatible with
> decentralised reconciliation - because deletion without permissions
> management is an open door, and permissions have to be enforced by an
> authority.
H the authority could
On 14/08/2019 11:39, Alessandro Vesely via Gnupg-users wrote:
> Absolute monotonicity is wrong. It must be possible to delete errors.
In that case we need a different algorithm.
Which I had already been advocating, so you are preaching to the choir.
You can keep reiterating that you do not like
On 13/08/2019 17:11, Robert J. Hansen wrote:
>> I think the proper fix is to design an alternative to the SKS keyserver
>> network. The design choices in the reconciliation protocol don't work
>> out anymore, we shouldn't change the protocol but replace it.
>
> I agree.
Ah, then the discussion
On 13/08/2019 13:56, Kristian Fiskerstrand wrote:
> As you correctly point out its really not that relevant for encryption
> subkeys. It does have security implementations for signing subkeys; see
> [cross-certification section] for some details on that.
But this issue has been fixed for so long
On 12/08/2019 22:09, U'll Be King Of The Stars wrote:
> The things I missed are:
>
> - how to check and clean a user's local keyring
>
> - how to update the user's local configuration in ~/.gnupg
I generally felt there was a lack of concise, complete instructions for
users, after the event. I
I suspect we haven't seen this issue being done in the real world before
because it is not a useful attack in many scenarios. It's just a nasty
DoS that can be avoided by not using the SKS keyserver network. I'm
completely speculating, but I think that the people who really want to
learn something
On 13/08/2019 09:54, Alessandro Vesely via Gnupg-users wrote:
> More than a reasonable number of signatures makes no sense in
> practice, so I agree lists should somehow be "fixed" so as not to
> accept an unreasonable number of signatures (reasonable == 2??)
Others tell us: the synchronization
On 12/08/2019 18:39, Stefan Claas via Gnupg-users wrote:
> Why was is then not fixed a decade ago, like it was done with 2.2.17?
There is no fix for the SKS keyserver network, which explains why it
wasn't fixed in 2.2.17 either. In fact, fixes have been deployed over
the last several years. DANE,
On 05/07/2019 11:15, Wiktor Kwapisiewicz via Gnupg-users wrote:
> I did a small experiment and it seems that your data is permanently
> preserved in sigchains of all people that follow you. Even if you
> delete your account.
Plus, the data is preserved in different places such as archive.org,
On 03/07/2019 16:55, Werner Koch wrote:
> And well, self-sigs-only is a less intrusive change than changing
> import-minimal. If it breaks something it can easily be reverted by the
> user - a change to the semantics of import-minimal can't be reverted by
> the user.
Ah, yes, I had completely
On 03/07/2019 18:37, Stefan Claas via Gnupg-users wrote:
> Why so upset?
>
> I think I am allowed here to post my opinion and I do no "force"
> people.
You just said that if only you had the time and money, you would try to
take down the SKS network using a legal procedure. A procedure meant to
On 03/07/2019 17:33, Stefan Claas via Gnupg-users wrote:
> Mmmhhh...Peter, if I should do this it should serve as help guideline
> for users wishing to do the same.
>
> Why?
Pfah. Stop rationalising. If this is your concern, create a website
where your offer your services to people wishing to do
On 03/07/2019 16:59, Stefan Claas via Gnupg-users wrote:
> Or do SKS key servers dictate how GnuPG's submission / receiving
> protocol must work?
It's in the reconsiliation protocol and the very foundation of the
assumptions of the synchronizing keyserver network. GnuPG doesn't come
anywhere near
On 03/07/2019 16:00, Stefan Claas via Gnupg-users wrote:
> If I had time and money I would hire a lawyer, would formulate a letter
> for SKS operators stating that I request the removal of my pub key data
> and would as EU citizen refer in this letter to our GDPR.
Do you object to your data
AC46EFE6DE500B3E: 2 signatures not checked due to missing keys
gpg: key AC46EFE6DE500B3E: "Peter Lebbing " not changed
gpg: Total number processed: 1
gpg: unchanged: 1
$ cat >.gnupg/dirmngr.conf <" not changed
gpg: Total number processed: 1
gpg: unchanged:
Hello Roland,
On 03/07/2019 15:00, Roland wrote:
> And for Enigmail: your suggestion or In the terminal, to edit
> ~/.gnupg/dirmngr.conf so as to say "keyserver
> hkps://keys.openpgp.org/" or, if that file does not exist to create it
> as per your suggestion.
I don't think Enigmail respects
Hi,
On 03/07/2019 15:10, Werner Koch wrote:
> Yes, as I wrote: 0.2s compared to 50s.
I fear we're miscommunicating, so let me try to rephrase it again. Sorry
for my persistence, it's only because I think we're miscommunicating and
it would be good if that could be fixed.
If
--keyserver-options
Hello,
On 03/07/2019 13:17, Werner Koch wrote:
> --keyserver-options recognizes all import options in addition to
> keyserver specific options.
But then import-minimal could be modified so it includes the behaviour
currently planned for self-sigs-only, and import-minimal could be made
the
Hello Roland,
> Hansen's and DKG's blog are only partly helpful. For example my Linux
> system seems to *not* have a ~/.gnupg/dirmngr.conf file at all (one
> of those files recommended for editing). I.e. Nautilus cannot find it.
The usual case on Linux systems is that if a configuration file
On 03/07/2019 11:59, Peter Lebbing wrote:
> What is the difference in the end result between --keyserver-options
> self-sigs-only and --import-options import-minimal?
Ah, based on a new message I just read the penny dropped. self-sigs-only
can be made a default because it only a
On 03/07/2019 09:13, Werner Koch via Gnupg-users wrote:
> The current state is that we keep only self-signatures and then then
> import again with import-clean (which is then basically identical to
> import-minimal).
What is the difference in the end result between --keyserver-options
On 01/07/2019 23:36, Stefan Claas via Gnupg-users wrote:
> I think *flame on* Werner does not need to change anything,
> because he is in the lucky position do get financed by
> the big boys, so I see no need for him to start doing something
> new like many others (with no financial support) do.
On 01/07/2019 23:55, Ryan McGinnis via Gnupg-users wrote:
> Null modem transfer of your messages? Yikes. To me that’s the issue
> with PGP in general as it relates to secure communications
None of any of the alternatives to OpenPGP you mention solve the issue
that a secure offline system sets
On 01/07/2019 11:54, Robert J. Hansen wrote:
> [...]
I think this mail sums up the most important points about this whole
ordeal very well. I completely, wholeheartedly agree. I encourage
everyone to re-read it and internalise it.
The only point not touched upon in this specific mail, I think,
> "Look, this one guy who just got mugged? [...]
I had to read it twice to distill what I think Mirimir meant, but I
think they meant that if you blacklist/blackhole all affected
certificates, you remove the incentive for the attackers to poison more
certificates since the poison can't spread to
On 06/05/2019 16:39, Stefan Claas wrote:
> Maybe I should set-up squid on a VPS and let people register from there,
> while keeping no log files. :-D
The only purpose of that would be to specifically subvert the intentions
and processes of ProtonMail. They have designed a system which chooses
On 06/05/2019 14:53, Jeff Allen wrote:
> It would be more trivial not to hash the number and say you did.
I think it's a worthwhile thing to point out that they state "because
hash functions are one-way functions, it is impossible to derive your
phone number [...]" without reservations, but that
Hello Stephan,
Something completely different.
What is that link with the binary data in your OP?
I did not click it because I don't know what binary data I'd be handing
to that site. But I see this text on the front page of that site:
> You can also earn FREE TELE TOKENS from our bounty or
On 16/04/2019 23:23, Ángel wrote:
> Of course, you could instead run gpg-agent from python and set
> GPG_AGENT_INFO there. The gpg python package is calling gpg under the
> hood, so it should pick the GPG_AGENT_INFO variable from the
> environment.
GPG_AGENT_INFO is obsolete and unused in GnuPG
On 13/04/2019 14:34, Peter Lebbing wrote:
> Either reload the agent (this will make it forget all passphrases)
Of course I should have made that explicit. You reload the agent by:
$ gpgconf --reload gpg-agent
I should mention this before you start figuring out a way to send it
SIGHUP (which
Hello!
On 13/04/2019 12:42, Walia, Gaurav (333G) via Gnupg-users wrote:
> * gpg --version
> o gpg (GnuPG) 2.0.22
This version is a full six years old. Not only is 2.0.22 unsupported,
the whole 2.0 branch has been end-of-life for a good bit more than a
year now.
How come you're using
On 12/04/2019 04:57, Matheus Afonso Martins Moreira wrote:
> Is this gpg-agent command not documented?
For direct interaction with the agent and scdaemon, my first
documentation source is always the inline help. Only when I need more
than that will I look for more sources.
Talking to scdaemon is
On 12/04/2019 01:32, Ángel wrote:
> The alias will only be expanded on an interactive shell
Thanks for this piece of information! I'm rather cautious when it comes
to these shell modes of operation. I think I'm understanding it
reasonably well now, but have been surprised about behaviour in the
On 11/04/2019 16:06, Matheus Afonso Martins Moreira wrote:
> Public key list confirmed deletion of the subkeys from my public key
> but the secret key list still included all my revoked subkeys.
Could you provide an example? I find this rather surprising, that -K
would ever list more than -k.
>
On 11/04/2019 02:37, Ángel wrote:
> Why should I need to remember to manually add that .'2' every time?
Because, as I said, it might silently corrupt the functioning of a
utility that expects "gpg" to be 1.4 and not 2.1. There are quite a lot
of utilities out there that parse the output of the
On 10/04/2019 17:24, Peter Lebbing wrote:
> gpg> delkey
Sorry, my fatigued head was being silly. That's for deleting the public
part, not the secret part. I don't think I know the way to delete the
secret part when you just want to delete some subkey.
Sorry,
Peter.
--
I use the GNU P
On 10/04/2019 15:25, Matheus Afonso Martins Moreira wrote:
> If not, what is the correct way to do this?
$ gpg --edit-key [KEYID]
gpg> key N
gpg> delkey
Where N is the number of the subkey you want to delete; they are
numbered 1 for the first one listed and so on. It will indicate with a
"*"
Sorry for the noise. This message was intended to go to gnupg-devel, but
I screwed up. Please ignore it.
Peter.
--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at
I agree that GnuPG would benefit from preferring keys that are
available, both in the sense of different subkeys and different
smartcards with copies of the same subkey, in the sense you describe.
But let me pick out one detail you mentioned that is a different issue.
On 10/04/2019 09:38,
Hi André,
On 06/04/2019 21:21, André Ockers wrote:
> which would probably be a bad idea, wouldn't it?
Quite! :-)
Your operating system probably still requires GnuPG 1.4, so you can't
remove it. But you can solemnly pledge not to use it... I wouldn't mess
with the "gpg" binary, though. Don't use
On 06/04/2019 18:50, Jean-David Beyer via Gnupg-users wrote:
> Mine's bigger than yours (older, too):
>
> $ gpg --version
> gpg (GnuPG) 2.0.14
Yeah, and it's probably high time to put gramps out to pasture as
well... ;-) That's a seriously old, unsupported version.
Peter.
--
I use the GNU
On 06/04/2019 20:24, André Ockers wrote:
>>> gpg: secret key "7CD3FBC8F6005ED5" not found: eof
> I'm using (up to date) Trisquel
>
> $ gpg --version
> gpg (GnuPG) 1.4.20
>
> $ gpg2 --version
> gpg (GnuPG) 2.1.11
> libgcrypt 1.6.5
The error message is really unclear, but the problem probably is
Hi Jennifer,
On 04/04/2019 16:16, Mead, Jennifer wrote:
> What other folks are struggling with (just guessing this is the issue)
> is that when they dump the public key (to move to another server and
> add to the authorized_keys file) they get a different style output
> than I do. I get a string
On 04/04/2019 14:06, Thomas Glanzmann wrote:
> I'm looking for a recommendation for a cardsized 4 kbit RSA smartcard
> with 3 keyslots
Well, the ZeitControl card, which was the first OpenPGP Card on the
market, is now at version 3.3 which would seem to support what you ask
for.[1] I have no
On 04/04/2019 14:03, Thomas Glanzmann wrote:
> Is there a configuration option that I can specify so that gpg gives
> up is there is no socket or no agent behind a socket instead of
> starting a new agent?
From the man page:
| --no-autostart
| Do not start the gpg-agent or the dirmngr if
Hello Shweta,
Seeing how you did not start a new thread, I get the feeling we "scared
you off" from posting. That is really unfortunate, and not our intention
at all. I'm sorry if you felt intimidated by the response you got.
It's rather unusual, but I took the liberty of posting your question
Hello Shweta,
> gpg --batch --passphrase-fd n and it stops popup which asks for the
> passphrase. but when I run this command on window server 12 it's not
> working its always show popup for the passphrase.
It is not clear to me which versions of GnuPG you are using. Using a
recent version, but
I'm reposting a question[1] asked by Shweta Tyagi in a different thread,
so it is in its own thread. I feel Shweta might have chosen to seek
their answer elsewhere after they only got unhelpful responses there,
and I'd like to rectify that.
Shweta asked:
Hi All,
I am using the following command
Hi Shweta,
On 26/03/2019 12:30, Shweta Tyagi wrote:
> How can start a new thread? Please advise.
Start a new e-mail (rather than replying to one), and address it to
. That will start a new thread.
Oh, I forgot this the previous time, but some mailing list members
might appreciate it if you send
Hi,
On 26/03/2019 12:20, Shweta Tyagi wrote:
> gpg --batch --passphrase-fd n and it stops popup which asks for the
> passphrase
Please start a new thread with your question, it is something completely
different than the thread you replied to.
Thanks,
Peter.
--
I use the GNU Privacy Guard
On 26/03/2019 09:16, Werner Koch wrote:
> This lists all keys allowed for ssh with its keygrip (1234. and the
> corresponding ssh fingerprint (SHA256:PTJI). Details as usual by using
> 'help keyinfo'.
Right, yes, the comment lines in sshcontrol are also really helpful for
keys in sshcontrol.
I
On 25/03/2019 15:45, Werner Koch wrote:
> That is on purpose: gpg-agent stores the key permanently and thus it
> makes no sense to add and remove it regularly.
It might also be "slightly annoying" to remove key material which is
also in use for other purposes :-). You remove an SSH key, and
On 23/03/2019 13:39, Brian Exelbierd wrote:
> How did you import this key?
If your OpenSSH private key is .ssh/id_ed25519, and you are running
gpg-agent as your SSH agent, it's a matter of:
$ ssh-add ~/.ssh/id_ed25519
Any comment on the private key that was already there (presumably
through
On 17/03/2019 13:17, Brian Exelbierd wrote:
> Having done no code examination, I feel like this is where the
> identity information for subkeys comes into play. I presume the SSH
> request would pass the value of the identity file to the gpg-agent.
> This is probably 100% wrong though/
30%
On 17/03/2019 12:45, Brian Exelbierd wrote:
> There is no longer an identityfile to use in the .ssh/config file
> which means all auth keys are tried with all hosts. I have multiple
> auth keys and the hosts give up after 2 or 3 failures. How can I get
> the right key served to the right host
Hi,
On 16/03/2019 14:22, Dirk Gottschalk wrote:
> In the output from --export-ssh-key is also a comment field. This
> fieldd, in my case shows: openpgp:0xF852DAEE
Yes, but it is only added by the --export-ssh-key command and has a
fixed form. Instead, for my keys, which by the way are not part
On 16/03/2019 11:11, Wolfgang Traylor wrote:
> $ gpg2 --export-ssh-key
Actually, if you want a specific subkey, you need to append a ! to the
key ID (probably need to quote it as well for the shell, \! ).
Otherwise, GnuPG will use key selection rules to take the latest
authentication subkey from
Hi Brian,
On 15/03/2019 23:28, Brian Exelbierd wrote:> Hi,
> Either way, I am unsure how to identify which subkey is which SSH key.
Provided the auth keys are in your .gnupg/sshcontrol file, the following
will help:
--8<---cut here---start->8---
$ ssh-add -L
On 15/03/2019 20:26, Daniel wrote:
> If I may ask you again how your input was meant dear Peter, I should
> add code inline in the future like so(?):
>
> --8<---cut here---start->8---
> dm@dm-ThinkPad-X240:/boot$ sudo apt-get autoremove
>
On 13/03/2019 14:21, David wrote:
> If someone posts hundreds of kilobytes or more, I agree,
> but in this case I argue the opposite, for these reasons.
I fully agree. In fact, I much prefer someone include a lot of
information and maybe include too much than that the person trying to
help has to
On 23/02/2019 12:43, Chris Coutinho wrote:
> I'm not exactly sure what the difference is between that and a fingerprint
A key's fingerprint is something specific to OpenPGP. It includes
OpenPGP-specific information and formats. As such, it is undefined for
an OpenSSH key or a CMS (X.509) key; it
On 18/02/2019 22:39, Farhan Khan via Gnupg-users wrote:
> $ gpg --list-secret-keys farhan@farhan.codes
> sec> rsa2048 2019-02-18 [SCEA] [expires: 2021-02-17]
Ah, well, there's your problem.
You should not use your primary key for encryption; they invented
subkeys for that.
And with the
On 18/02/2019 06:51, Farhan Khan via Gnupg-users wrote:
> This was it, loading a 2048-bit key works just fine
> Thanks Andrew!
First of all, I think it's a much better idea to generate a 2048-bit key
anyway, so it worked out okay.
But the problem is interesting. Before --card-edit gained its
Hi André,
On 16/02/2019 10:34, André Ockers wrote:
>> /etc/mailname: hostname.digitalbrains.com (the actual fully qualified
>> domain name of the local host)
>
> So what do you do here if you have an emailadress, like
> an...@ockers.eu
> at an email service provider, let's say
>
Hi André,
On 10/02/2019 15:36, André Ockers wrote:
> Following documentation [1], I checked that I have Postfix installed and
> now I'm here [2]
I had feared it would break down at the mail configuration stage :-). I
have mail servers running with a hand-managed config file with Exim 4,
but I
Hello André,
On 09/02/2019 09:06, André Ockers wrote:
> - 171 official keysigning party participants, of who 107 showed up to my
> awareness;
This is going to be a pain to do manually. But you don't have to! As the
FOSDEM keysigning party page[1] notes, "You may find caff a helpful tool."
(last
On 01/02/2019 17:37, Stefan Claas wrote:
> Tesseract did not do a good job, to many errors.
Just an idea: OCR'ing a special OCR font like the two classics I
mentioned will go a lot better if the OCR engine *knows* it is looking
at that font. They designed the glyphs to be dissimilar. I don't know
(Changed the subject because we went off-topic on an off-topic thread
and in doing so went back on-topic for the mailing list! :-)
On 30/01/2019 20:44, Stefan Claas wrote:
> But which one ... ;-) I may check this again with a friend.
Well there are the classical options:
1 - 100 of 1316 matches
Mail list logo
