Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #236214 > unrolled thread

apt-key says deprecated, but not saying what else to use

Back to article view | Back to linux.debian.user

Contents

  apt-key says deprecated, but not saying what else to use Marco Möller <talby@debianlists.mobilxpress.net> - 2021-06-19 22:10 +0200
    Bug#990086: apt-key is deprecated in bullseye, how to manage keys instead Andrei POPESCU <andreimpopescu@gmail.com> - 2021-06-20 09:30 +0200
      Re: Bug#990086: apt-key is deprecated in bullseye, how to manage  keys instead Andrei POPESCU <andreimpopescu@gmail.com> - 2021-06-21 08:00 +0200
        Re: Bug#990086: apt-key is deprecated in bullseye, how to manage keys  instead Marco Möller <talby@debianlists.mobilxpress.net> - 2021-06-24 16:50 +0200
          Re: Bug#990086: apt-key is deprecated in bullseye, how to manage  keys instead Andrei POPESCU <andreimpopescu@gmail.com> - 2021-06-26 12:00 +0200
            Re: Bug#990086: apt-key is deprecated in bullseye, how to manage keys  instead Marco Möller <talby@debianlists.mobilxpress.net> - 2021-06-26 13:10 +0200
            Re: Bug#990086: apt-key is deprecated in bullseye, how to manage keys instead Cindy Sue Causey <butterflybytes@gmail.com> - 2021-06-26 14:50 +0200
              Re: Bug#990086: apt-key is deprecated in bullseye, how to manage  keys instead <tomas@tuxteam.de> - 2021-06-26 21:00 +0200
                Re: Bug#990086: apt-key is deprecated in bullseye, how to manage keys instead Nicholas Geovanis <nickgeovanis@gmail.com> - 2021-06-29 03:10 +0200
    Re: apt-key says deprecated, but not saying what else to use Darac Marjal <mailinglist@darac.org.uk> - 2021-06-20 14:20 +0200
      Re: apt-key says deprecated, but not saying what else to use Gene Heskett <gheskett@shentel.net> - 2021-06-20 14:50 +0200
        Re: apt-key says deprecated, but not saying what else to use Dan Ritter <dsr@randomstring.org> - 2021-06-20 16:30 +0200
          Re: apt-key says deprecated, but not saying what else to use Charles Curley <charlescurley@charlescurley.com> - 2021-06-20 17:30 +0200
          Re: apt-key says deprecated, but not saying what else to use Gene Heskett <gheskett@shentel.net> - 2021-06-20 17:40 +0200
          Re: apt-key says deprecated, but not saying what else to use Gene Heskett <gheskett@shentel.net> - 2021-06-20 19:00 +0200
            Re: apt-key says deprecated, but not saying what else to use <tomas@tuxteam.de> - 2021-06-20 19:10 +0200
            Re: apt-key says deprecated, but not saying what else to use Greg Wooledge <greg@wooledge.org> - 2021-06-20 21:10 +0200
              Re: apt-key says deprecated, but not saying what else to use Dan Ritter <dsr@randomstring.org> - 2021-06-20 21:20 +0200
            Re: apt-key says deprecated, but not saying what else to use Dan Ritter <dsr@randomstring.org> - 2021-06-20 21:10 +0200
          Re: apt-key says deprecated, but not saying what else to use Jonathan Dowland <jon+debian-user@dow.land> - 2021-06-21 11:10 +0200
      Re: apt-key says deprecated, but not saying what else to use Marco Möller <talby@debianlists.mobilxpress.net> - 2021-06-24 14:50 +0200
    Re: apt-key says deprecated, but not saying what else to use Brad Rogers <brad@fineby.me.uk> - 2021-06-20 18:10 +0200
      Re: apt-key says deprecated, but not saying what else to use Marco Möller <talby@debianlists.mobilxpress.net> - 2021-06-24 15:20 +0200

Page 1 of 2  [1] 2  Next page →

#236214 — apt-key says deprecated, but not saying what else to use

Hello,
Command apt-key and its man page say that apt-key is deprecated, but do 
not suggest an instead recommended tool. It is only mentioned that keys 
would now be organized in /etc/apt/trusted.gpg.d/  . But how should I 
manage the keys saved there, for instance how to update them, or what 
tool of the Debian distribution is managing them there for the apt 
functionality of the Debian OS?
Guiding me to a properly up-to-date documentation about this topic would 
be welcome!
Marco.

[toc] | [next] | [standalone]

#236218 — Bug#990086: apt-key is deprecated in bullseye, how to manage keys instead

[Multipart message — attachments visible in raw view] — view raw

Package: release-notes
X-Debbugs-Cc: debian-user@lists.debian.org, apt@packages.debian.org

On Sb, 19 iun 21, 22:07:35, Marco Möller wrote:
> 
> Command apt-key and its man page say that apt-key is deprecated, but do not
> suggest an instead recommended tool. It is only mentioned that keys would
> now be organized in /etc/apt/trusted.gpg.d/  . But how should I manage the
> keys saved there, for instance how to update them, or what tool of the
> Debian distribution is managing them there for the apt functionality of the
> Debian OS?

As far as I understand it's as simple as dropping the keys in there. 

When a key changes/expires/etc. replace it with the new one (if provided 
by the respective repository).

> Guiding me to a properly up-to-date documentation about this topic would be
> welcome!

Indeed the documentation on this is a bit scarce, probably worth a 
mention in the Release Notes.

Dear APT maintainers,

The short version appears to be this note to the 'add' command from 
apt-key(8):

    Note: Instead of using this command a keyring should be placed 
    directly in the /etc/apt/trusted.gpg.d/ directory with a descriptive 
    name and either "gpg" or "asc" as file extension.

where .gpg files are of type created with 'gpg --export' and .asc with
'gpg --armor --export'.


Your confirmation (or even better, proposes wording) would be much 
appreciated.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#236235 — Re: Bug#990086: apt-key is deprecated in bullseye, how to manage keys instead

[Multipart message — attachments visible in raw view] — view raw

On Du, 20 iun 21, 10:20:42, Andrei POPESCU wrote:
> Package: release-notes
> X-Debbugs-Cc: debian-user@lists.debian.org, apt@packages.debian.org
> 
> On Sb, 19 iun 21, 22:07:35, Marco Möller wrote:
> > 
> > Command apt-key and its man page say that apt-key is deprecated, but do not
> > suggest an instead recommended tool. It is only mentioned that keys would
> > now be organized in /etc/apt/trusted.gpg.d/  . But how should I manage the
> > keys saved there, for instance how to update them, or what tool of the
> > Debian distribution is managing them there for the apt functionality of the
> > Debian OS?
> 
> As far as I understand it's as simple as dropping the keys in there. 
> 
> When a key changes/expires/etc. replace it with the new one (if provided 
> by the respective repository).
> 
> > Guiding me to a properly up-to-date documentation about this topic would be
> > welcome!
> 
> Indeed the documentation on this is a bit scarce, probably worth a 
> mention in the Release Notes.

Which already exists, under "Deprecated components for bullseye".

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#236418 — Re: Bug#990086: apt-key is deprecated in bullseye, how to manage keys instead

On 21.06.21 07:58, Andrei POPESCU wrote:
> On Du, 20 iun 21, 10:20:42, Andrei POPESCU wrote:
>> Package: release-notes
>> X-Debbugs-Cc: debian-user@lists.debian.org, apt@packages.debian.org
>>
>> On Sb, 19 iun 21, 22:07:35, Marco Möller wrote:
>>>
>>> Command apt-key and its man page say that apt-key is deprecated, but do not
>>> suggest an instead recommended tool. It is only mentioned that keys would
>>> now be organized in /etc/apt/trusted.gpg.d/  . But how should I manage the
>>> keys saved there, for instance how to update them, or what tool of the
>>> Debian distribution is managing them there for the apt functionality of the
>>> Debian OS?
>>
>> As far as I understand it's as simple as dropping the keys in there.
>>
>> When a key changes/expires/etc. replace it with the new one (if provided
>> by the respective repository).
>>
>>> Guiding me to a properly up-to-date documentation about this topic would be
>>> welcome!
>>
>> Indeed the documentation on this is a bit scarce, probably worth a
>> mention in the Release Notes.
> 
> Which already exists, under "Deprecated components for bullseye".
> 
> Kind regards,
> Andrei
> 

Andrei, thanks for having picked up my problem and having cared for the 
release notes to comment on it, and also for supposedly having motivated 
Julian Andres Klose to publish a very helpful blog post on the related 
subject. Brad Rogers here in the thread linked to it in his answer to 
me, thanks also for this.
Darac Marjal in his answer made me understood, that my problem was NOT 
about knowing how to copy a key file to a directory, but about being 
convinced that it is allowed to simply copy files to the 
/etc/apt/trusted.gpg.d/ sub-directory without having to manage this by a 
special tool like gpg. For convincing me, maybe the man page of apt-key 
was simply missing a word like "manually" for expressing to "manually 
place files in this sub-director". As a beginner being confronted with 
security relevant procedures, specially when it is about things like PGP 
keys based on a Web Of Trust concept, you easily suspect that a special 
security tool would exist for ensuring that handling the important 
package signature key infrastructure is done correctly. Obviously not. 
Simply copying a key there appears is really enough to get access to a 
repository.

I stumbled over this problem with apt-key because I am learning to make 
use of openPGP right now, therefore studying GnuPG and its gpg tool, and 
by this approaching how I maybe could also make use of the package 
signatures to review if my OS installation was manipulated in an 
unauthorized way after by me requested package installations, only to 
find that the tool apt-key mentioned in this context by the "Securing 
Debian Manual" is deprecated already.
Obviously, being new to this topic, I was then not properly separating 
the concept of gpg being a tool to manage openPGP keys, but the keys not 
necessarily having to be tightly bound to the keyrings which as a user I 
can manage with the gpg command. Insights about my apt-key related 
findings derived from the answer of Darac Marjal, from the blog post of 
Julian Andres Klose, and from many(!) other texts about openPGP and 
GnuPG which I studied in the last days, I have summarized by the 
following words in my answer to Darac Marjal. Maybe these words can also 
serve for the documentation of the deprecation of the apt-key command 
and for the documentation of the usage of the /etc/apt/trusted.gpg.d/ 
sub-directory? Here my words, hoping they are describing the situation 
correctly:

--> "    The gpg keys in the /etc/apt/trusted.gpg.d/ sub-directory are 
managed by apt after simply having placed manually the files there, each 
file containing a binary formatted key. These keys are automatically 
trusted by apt and hence the "trusted.gpg.d" label for that 
sub-directory. Keys at this location are not related to the openPGP key 
management which as a user is usually done with the explicit use of the 
gpg command. Because of apt internally managing these keys and these 
keys not intended to become manipulated manually with the gpg command by 
the system administrating user, the gpg command --refresh-keys cannot be 
used as a replacement for the deprecated "apt-key update" command.    " <--

It then might be recommended to also add something like the following to it:
"  Although not needed for technical functionality, it is highly 
recommended to confirm that a key indeed belongs to the package provider 
before adding the binary key containing file to this sub-directory. 
Further reading on the best practice of how to confirm this is provided 
in ....  "    here needs to come a good link suggestion, which I do not 
have right now.

I could imagine, that the link could point to Chapter 7.5 "Package 
signing in Debian" of the "Securing Debian Manual" ( 
https://www.debian.org/doc/user-manuals#securing ) - after this chapter 
would have been updated to the current situation, apt-key is obviously 
deprecated, and adding maybe there a small advise on how to check a key 
file for its signatures acting as the Web Of Trust.

Best regards, Marco.

[toc] | [prev] | [next] | [standalone]

#236473 — Re: Bug#990086: apt-key is deprecated in bullseye, how to manage keys instead

[Multipart message — attachments visible in raw view] — view raw

On Jo, 24 iun 21, 16:42:34, Marco Möller wrote:
> On 21.06.21 07:58, Andrei POPESCU wrote:
> > On Du, 20 iun 21, 10:20:42, Andrei POPESCU wrote:
> > > Package: release-notes
> > > X-Debbugs-Cc: debian-user@lists.debian.org, apt@packages.debian.org
> > > 
> > > On Sb, 19 iun 21, 22:07:35, Marco Möller wrote:
> > > > 
> > > > Command apt-key and its man page say that apt-key is deprecated, but do not
> > > > suggest an instead recommended tool. It is only mentioned that keys would
> > > > now be organized in /etc/apt/trusted.gpg.d/  . But how should I manage the
> > > > keys saved there, for instance how to update them, or what tool of the
> > > > Debian distribution is managing them there for the apt functionality of the
> > > > Debian OS?
> > > 
> > > As far as I understand it's as simple as dropping the keys in there.
> > > 
> > > When a key changes/expires/etc. replace it with the new one (if provided
> > > by the respective repository).
> > > 
> > > > Guiding me to a properly up-to-date documentation about this topic would be
> > > > welcome!
> > > 
> > > Indeed the documentation on this is a bit scarce, probably worth a
> > > mention in the Release Notes.
> > 
> > Which already exists, under "Deprecated components for bullseye".
> > 
> > Kind regards,
> > Andrei
> > 
> 
> Andrei, thanks for having picked up my problem and having cared for the
> release notes to comment on it, and also for supposedly having motivated
> Julian Andres Klose to publish a very helpful blog post on the related
> subject. Brad Rogers here in the thread linked to it in his answer to me,
> thanks also for this.
> Darac Marjal in his answer made me understood, that my problem was NOT about
> knowing how to copy a key file to a directory, but about being convinced
> that it is allowed to simply copy files to the /etc/apt/trusted.gpg.d/
> sub-directory without having to manage this by a special tool like gpg. For
> convincing me, maybe the man page of apt-key was simply missing a word like
> "manually" for expressing to "manually place files in this sub-director". As
> a beginner being confronted with security relevant procedures, specially
> when it is about things like PGP keys based on a Web Of Trust concept, you
> easily suspect that a special security tool would exist for ensuring that
> handling the important package signature key infrastructure is done
> correctly. Obviously not. Simply copying a key there appears is really
> enough to get access to a repository.

Well, it makes perfect sense if you remember that "everything is a 
file", even if there are exceptions (e.g. network devices).

Documentation for actions requiring specialized tools is rather of the 
form "use foo to add an entry to baz", e.g. in the context of GnuPG it 
would be "use gpg to add this public key to <keyring>" (which is also a 
file, but must be manipulated with specialized tools).
 
> Here my words, hoping they are describing the situation correctly:
> 
> --> "    The gpg keys in the /etc/apt/trusted.gpg.d/ sub-directory are
> managed by apt after simply having placed manually the files there, each
> file containing a binary formatted key.

To me managing implies that apt is somehow able to add, remove and 
possibly refresh them, which is exactly the issue you stumbled upon. In 
my opinion a better wording would be:

    The keys in the /etc/apt/trusted.gpg.d/ sub-directory are managed by 
    the system administrator, by copying the corresponding public key of 
    each repository in the directory as a separate file, either in gpg 
    binary format or ASCII armored format.

> These keys are automatically trusted
> by apt and hence the "trusted.gpg.d" label for that sub-directory.

Ok, with a minor nitpick: in my opinion it's better to use uppercase APT 
when talking about the Advanced Package Tool and lowercase `apt` when 
talking about the (not so new anymore) command-line tool.

Can't find a good reference for this at the moment.

> Keys at
> this location are not related to the openPGP key management which as a user
> is usually done with the explicit use of the gpg command. Because of apt
> internally managing these keys and these keys not intended to become
> manipulated manually with the gpg command by the system administrating user,
> the gpg command --refresh-keys cannot be used as a replacement for the
> deprecated "apt-key update" command.    " <--

Do you still think this is needed after my rewording above?

> It then might be recommended to also add something like the following to it:
> "  Although not needed for technical functionality, it is highly recommended
> to confirm that a key indeed belongs to the package provider before adding
> the binary key containing file to this sub-directory. Further reading on the
> best practice of how to confirm this is provided in ....  "    here needs to
> come a good link suggestion, which I do not have right now.

Yes, something like this would be a good idea in my opinion. Most 
third-party repositories out there just provide some commands to be 
executed with root privileges.

The steps are likely to involve using gpg to inspect the key and 
signatures on it without actually importing it to the user's keyring. 
Which incidentally could also be part of installing that key, if the 
last step involves some version of 'gpg --export | sudo tee'.

However, this implies the key is actually published on GPG servers, 
which might not always be the case. There is nothing stopping a 
repository maintainer to generate a key, place it on some website for 
others to download and use "to make APT happy", but never bother to get 
signatures for it and publish the signed key on GPG servers.

> I could imagine, that the link could point to Chapter 7.5 "Package signing
> in Debian" of the "Securing Debian Manual" (
> https://www.debian.org/doc/user-manuals#securing ) - after this chapter
> would have been updated to the current situation, apt-key is obviously
> deprecated, and adding maybe there a small advise on how to check a key file
> for its signatures acting as the Web Of Trust.

Feel free to suggest patches for it through bugs against the harden-doc 
package, or merge requests in Salsa if the Maintainer is accepting them.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#236478 — Re: Bug#990086: apt-key is deprecated in bullseye, how to manage keys instead

On 26.06.21 11:54, Andrei POPESCU wrote:
> (...)

Very good points, all appreciated.

> Feel free to suggest patches for it through bugs against the harden-doc
> package, or merge requests in Salsa if the Maintainer is accepting them.

I'll do so. I decided, motivated also by observing how you are doing it, 
to become more active in this regard.  :-)

Thanks a lot! Marco.

[toc] | [prev] | [next] | [standalone]

#236485 — Re: Bug#990086: apt-key is deprecated in bullseye, how to manage keys instead

On 6/26/21, Andrei POPESCU <andreimpopescu@gmail.com> wrote:
>> Andrei, thanks for having picked up my problem and having cared for the
>> release notes to comment on it, and also for supposedly having motivated
>> Julian Andres Klose to publish a very helpful blog post on the related
>> subject. Brad Rogers here in the thread linked to it in his answer to me,
>> thanks also for this.
>> Darac Marjal in his answer made me understood, that my problem was NOT
>> about
>> knowing how to copy a key file to a directory, but about being convinced
>> that it is allowed to simply copy files to the /etc/apt/trusted.gpg.d/
>> sub-directory without having to manage this by a special tool like gpg.
>> For
>> convincing me, maybe the man page of apt-key was simply missing a word
>> like
>> "manually" for expressing to "manually place files in this sub-director".
>> As
>> a beginner being confronted with security relevant procedures, specially
>> when it is about things like PGP keys based on a Web Of Trust concept,
>> you
>> easily suspect that a special security tool would exist for ensuring that
>> handling the important package signature key infrastructure is done
>> correctly. Obviously not. Simply copying a key there appears is really
>> enough to get access to a repository.
>
> Well, it makes perfect sense if you remember that "everything is a
> file", even if there are exceptions (e.g. network devices).


Hopefully I'm reading this right. While on dialup, I spent A LOT of
time battling a well-known closed source modem tty* driver. Out of
desperation, I could sometimes get it to work by copying it between
hard drives that contained separate operating systems.

BUT you can't just e.g. "cp" or "right click > copy" it over. It would
fail with a "Can't copy special file" error message. I know this
because I just did it again with ttyS0. You CAN rsync it between
partitions, and it would be viable, usable.


> Documentation for actions requiring specialized tools is rather of the
> form "use foo to add an entry to baz", e.g. in the context of GnuPG it
> would be "use gpg to add this public key to <keyring>" (which is also a
> file, but must be manipulated with specialized tools).


Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with birdseed *

[toc] | [prev] | [next] | [standalone]

#236502 — Re: Bug#990086: apt-key is deprecated in bullseye, how to manage keys instead

[Multipart message — attachments visible in raw view] — view raw

On Sat, Jun 26, 2021 at 08:42:26AM -0400, Cindy Sue Causey wrote:
> On 6/26/21, Andrei POPESCU <andreimpopescu@gmail.com> wrote:

[...]

> > Well, it makes perfect sense if you remember that "everything is a
> > file", even if there are exceptions (e.g. network devices).
> 
> 
> Hopefully I'm reading this right. While on dialup, I spent A LOT of
> time battling a well-known closed source modem tty* driver. Out of
> desperation, I could sometimes get it to work by copying it between
> hard drives that contained separate operating systems.
> 
> BUT you can't just e.g. "cp" or "right click > copy" it over. It would
> fail with a "Can't copy special file" error message. I know this
> because I just did it again with ttyS0. You CAN rsync it between
> partitions, and it would be viable, usable.

Wait a sec. You are not trying to copy /dev/ttyS0 (or its kin)?

Because that won't really make much sense. Or, well, it will perhaps
do surprising things.

See, /dev/ttyS0 is a representation of an external device (your first
serial interface, if your computer still has such a thing). You can
open it, read from it (which will yield incoming characters), write
to it (which will send the characters out, if all goes well) -- so
to your applications it presents an interface similar to the one
a file presents. This is Andrei's quote "everything is a file".

If you now copy /dev/ttyS0 to /tmp, e.g.

  sudo cp /dev/ttyS0 /tmp

and assuming there's something connected to it and sending us characters,
there will be an ever-growing /tmp/ttyS0 and the copy will terminate
the moment the serial connection's other side "hangs up".

Now if you do

  sudo cp -a /dev/ttyS0 /tmp

you get something completely different: a device file (referring to the
exact same device as your original).

Don't forget to remove them after: your system administrator might get
mighty confused finding a device file in /tmp :-)

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#236584 — Re: Bug#990086: apt-key is deprecated in bullseye, how to manage keys instead

[Multipart message — attachments visible in raw view] — view raw

Perhaps it should be said that personal use of gpg and the use that a
system administrator makes of it and key-ing are different use-cases. So we
might expect fewer assumptions to hold and greater mystery :-)

On Sat, Jun 26, 2021, 1:53 PM <tomas@tuxteam.de> wrote:

> On Sat, Jun 26, 2021 at 08:42:26AM -0400, Cindy Sue Causey wrote:
> > On 6/26/21, Andrei POPESCU <andreimpopescu@gmail.com> wrote:
>
> [...]
>
> > > Well, it makes perfect sense if you remember that "everything is a
> > > file", even if there are exceptions (e.g. network devices).
> >
> >
> > Hopefully I'm reading this right. While on dialup, I spent A LOT of
> > time battling a well-known closed source modem tty* driver. Out of
> > desperation, I could sometimes get it to work by copying it between
> > hard drives that contained separate operating systems.
> >
> > BUT you can't just e.g. "cp" or "right click > copy" it over. It would
> > fail with a "Can't copy special file" error message. I know this
> > because I just did it again with ttyS0. You CAN rsync it between
> > partitions, and it would be viable, usable.
>
> Wait a sec. You are not trying to copy /dev/ttyS0 (or its kin)?
>
> Because that won't really make much sense. Or, well, it will perhaps
> do surprising things.
>
> See, /dev/ttyS0 is a representation of an external device (your first
> serial interface, if your computer still has such a thing). You can
> open it, read from it (which will yield incoming characters), write
> to it (which will send the characters out, if all goes well) -- so
> to your applications it presents an interface similar to the one
> a file presents. This is Andrei's quote "everything is a file".
>
> If you now copy /dev/ttyS0 to /tmp, e.g.
>
>   sudo cp /dev/ttyS0 /tmp
>
> and assuming there's something connected to it and sending us characters,
> there will be an ever-growing /tmp/ttyS0 and the copy will terminate
> the moment the serial connection's other side "hangs up".
>
> Now if you do
>
>   sudo cp -a /dev/ttyS0 /tmp
>
> you get something completely different: a device file (referring to the
> exact same device as your original).
>
> Don't forget to remove them after: your system administrator might get
> mighty confused finding a device file in /tmp :-)
>
> Cheers
>  - t
>

[toc] | [prev] | [next] | [standalone]

#236221

[Multipart message — attachments visible in raw view] — view raw

On 19/06/2021 21:07, Marco Möller wrote:
>
> Hello,
> Command apt-key and its man page say that apt-key is deprecated, but
> do not suggest an instead recommended tool. It is only mentioned that
> keys would now be organized in /etc/apt/trusted.gpg.d/  . But how
> should I manage the keys saved there, for instance how to update them,
> or what tool of the Debian distribution is managing them there for the
> apt functionality of the Debian OS?
> Guiding me to a properly up-to-date documentation about this topic
> would be welcome!
> Marco.

For some time, I've been using /etc/apt/trusted.gpg.d rather than using
apt-key. As I understand it, keys in apt-key are trusted to sign *any*
repository you pull from. That is, if you add a suspicious repository
and somehow they were able to push packages signed with their key to the
main debian repo servers, then you'd not be able to distinguish between
"signed by Debian" and "signed by attacker".

Instead, the preferred method is to put binary GPG keys into
/etc/apt/trusted.gpg.d (that is, you might need to run "gpg --dearmor"
if you download an ascii-armoured key). Files there can have any name
it's purely up to the system administrator what the names are, but it
makes sense that they indicate the repository they sign. Then, in
/etc/apt/sources.list.d/*.list, you need to write:

deb [signed-by=/etc/apt/trusted.gpg.d/somekey.gpg]
https://repo.attacker.com/ stable main

Now, only this repository trusts that key. If packages there are signed
by another key, verification fails. Similarly, if packages in another
repository are signed by that key, verification fails.

You ask about updating them. There is, as far as I know, no automatic
method for updating these keys, nor for automatically adding them right
now. That's because it's generally considered good practice to add the
key manually. You need to actively state that you trust this repository
on your system. So, for most repositories, that involves a web page
somewhere that says "This is our 'deb ... ' line and this is a link to
our public key." The key will usually be valid for several years, but if
it does start to fail, apt tools *will* tell you that the key has
expired, and that's time to go back and revisit the original site, and
see if they have a new key available.

[toc] | [prev] | [next] | [standalone]

#236222

On Sunday 20 June 2021 08:11:45 Darac Marjal wrote:

> On 19/06/2021 21:07, Marco Möller wrote:
> > Hello,
> > Command apt-key and its man page say that apt-key is deprecated, but
> > do not suggest an instead recommended tool. It is only mentioned
> > that keys would now be organized in /etc/apt/trusted.gpg.d/  . But
> > how should I manage the keys saved there, for instance how to update
> > them, or what tool of the Debian distribution is managing them there
> > for the apt functionality of the Debian OS?
> > Guiding me to a properly up-to-date documentation about this topic
> > would be welcome!
> > Marco.
>
> For some time, I've been using /etc/apt/trusted.gpg.d rather than
> using apt-key. As I understand it, keys in apt-key are trusted to sign
> *any* repository you pull from. That is, if you add a suspicious
> repository and somehow they were able to push packages signed with
> their key to the main debian repo servers, then you'd not be able to
> distinguish between "signed by Debian" and "signed by attacker".
>
> Instead, the preferred method is to put binary GPG keys into
> /etc/apt/trusted.gpg.d (that is, you might need to run "gpg --dearmor"
> if you download an ascii-armoured key). Files there can have any name
> it's purely up to the system administrator what the names are, but it
> makes sense that they indicate the repository they sign. Then, in
> /etc/apt/sources.list.d/*.list, you need to write:
>
> deb [signed-by=/etc/apt/trusted.gpg.d/somekey.gpg]
> https://repo.attacker.com/ stable main
>
> Now, only this repository trusts that key. If packages there are
> signed by another key, verification fails. Similarly, if packages in
> another repository are signed by that key, verification fails.
>
> You ask about updating them. There is, as far as I know, no automatic
> method for updating these keys, nor for automatically adding them
> right now. That's because it's generally considered good practice to
> add the key manually. You need to actively state that you trust this
> repository on your system. So, for most repositories, that involves a
> web page somewhere that says "This is our 'deb ... ' line and this is
> a link to our public key." The key will usually be valid for several
> years, but if it does start to fail, apt tools *will* tell you that
> the key has expired, and that's time to go back and revisit the
> original site, and see if they have a new key available.

I'd like to pleaed for a new apt-key, one that would survey the existing 
list, and on finding a key that is expired or is no longer associated, 
offer the option of removing it, or refreshiing it.

I have up to 7 machines on my local network, usually accessed by some 
ssh/sshfs variation, but my current keyring since I'm first user, 
probably has 30 some keys, many of which are useless as the target 
machine has been changed by a new machine and a new bare metal install.

I consider those "dead" keys to be security risks. But at present, there 
is not a means to identify and remove them that I am aware of.

So I would plead for an apt-key replacement that would automate that 
process. At the present state, my connection scripts to re-establlish my 
local network after a reboot or power failure recovery, are all blocked 
because of machine replacements/reinstalls using the same ip address 
yadda yadda, so I must answer yes, then supply my first user password 
for that machine because I do want to continue connecting to that 
machine. That can rapidly turn into a PITA.

Thanks for this thread.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#236223

Gene Heskett wrote: 
> I'd like to pleaed for a new apt-key, one that would survey the existing 
> list, and on finding a key that is expired or is no longer associated, 
> offer the option of removing it, or refreshiing it.
> 
> I have up to 7 machines on my local network, usually accessed by some 
> ssh/sshfs variation, but my current keyring since I'm first user, 
> probably has 30 some keys, many of which are useless as the target 
> machine has been changed by a new machine and a new bare metal install.

This is ssh key management, not apt key management. apt key
things are for trusting package repositories.

> I consider those "dead" keys to be security risks. But at present, there 
> is not a means to identify and remove them that I am aware of.
> 
> So I would plead for an apt-key replacement that would automate that 
> process. At the present state, my connection scripts to re-establlish my 
> local network after a reboot or power failure recovery, are all blocked 
> because of machine replacements/reinstalls using the same ip address 
> yadda yadda, so I must answer yes, then supply my first user password 
> for that machine because I do want to continue connecting to that 
> machine. That can rapidly turn into a PITA.

Here's what you should do:

1. create a new ssh keypair on your main machine:
    ssh-keygen -t rsa -b 4096 -f gene2021

2. for each $targetmachine in your 7 machines, do this:
    - ssh $targetmachine
    - mv ~/.ssh/authorized_keys ~/.ssh/authorized_keys_old
    - don't close that terminal 
    - open a new terminal and make sure you can ssh in by
      password, then
    - ssh-copy-id gene2021 $targetmachine
    - make sure you can ssh in with the gene2021 key:
      ssh -i gene2021 $targetmachine
    - if it's good, close both terminals and go on to the next
      $targetmachine

3. clean up: remove keys in ~/.ssh/  that aren't gene2021 and
   aren't useful otherwise.

Now you have one known good keypair that lets you in to all
seven machines without a password, and you can use a password as
fallback.

Now, it sounds like you also have a problem with machines
getting randomly assigned IP addresses. In a network of size 7,
I would strongly advise you to stop using DHCP and just put in 
static IP assignments for each machine in
/etc/network/interfaces.

-dsr-

[toc] | [prev] | [next] | [standalone]

#236224

On Sun, 20 Jun 2021 10:21:52 -0400
Dan Ritter <dsr@randomstring.org> wrote:

> Now, it sounds like you also have a problem with machines
> getting randomly assigned IP addresses. In a network of size 7,
> I would strongly advise you to stop using DHCP and just put in 
> static IP assignments for each machine in
> /etc/network/interfaces.

That certainly will work. Since Gene already has dhcp up and running,
he can also use it to assign fixed ip addresses, e.g.:

host orca                       # Lenovo T61                                                                                        
{
   option host-name "orca";
   hardware ethernet 00:13:8E:BA:7E:59;
   fixed-address 192.168.101.18;
   ddns-hostname orca;
}


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

#236225

On Sunday 20 June 2021 10:21:52 Dan Ritter wrote:

> Gene Heskett wrote:
> > I'd like to pleaed for a new apt-key, one that would survey the
> > existing list, and on finding a key that is expired or is no longer
> > associated, offer the option of removing it, or refreshiing it.
> >
> > I have up to 7 machines on my local network, usually accessed by
> > some ssh/sshfs variation, but my current keyring since I'm first
> > user, probably has 30 some keys, many of which are useless as the
> > target machine has been changed by a new machine and a new bare
> > metal install.
>
> This is ssh key management, not apt key management. apt key
> things are for trusting package repositories.
>
> > I consider those "dead" keys to be security risks. But at present,
> > there is not a means to identify and remove them that I am aware of.
> >
> > So I would plead for an apt-key replacement that would automate that
> > process. At the present state, my connection scripts to
> > re-establlish my local network after a reboot or power failure
> > recovery, are all blocked because of machine replacements/reinstalls
> > using the same ip address yadda yadda, so I must answer yes, then
> > supply my first user password for that machine because I do want to
> > continue connecting to that machine. That can rapidly turn into a
> > PITA.
>
> Here's what you should do:
>
> 1. create a new ssh keypair on your main machine:
>     ssh-keygen -t rsa -b 4096 -f gene2021
>
> 2. for each $targetmachine in your 7 machines, do this:
>     - ssh $targetmachine
>     - mv ~/.ssh/authorized_keys ~/.ssh/authorized_keys_old
>     - don't close that terminal
>     - open a new terminal and make sure you can ssh in by
>       password, then
>     - ssh-copy-id gene2021 $targetmachine
>     - make sure you can ssh in with the gene2021 key:
>       ssh -i gene2021 $targetmachine
>     - if it's good, close both terminals and go on to the next
>       $targetmachine
>
> 3. clean up: remove keys in ~/.ssh/  that aren't gene2021 and
>    aren't useful otherwise.
>
> Now you have one known good keypair that lets you in to all
> seven machines without a password, and you can use a password as
> fallback.
>
> Now, it sounds like you also have a problem with machines
> getting randomly assigned IP addresses. In a network of size 7,
> I would strongly advise you to stop using DHCP and just put in
> static IP assignments for each machine in
> /etc/network/interfaces.
>
> -dsr-
I haven't used dhcp in 23 years, don't even run a server in my dd-wrt 
router.  Used a hosts file on my first install in 1998, never saw an 
advantage to changing.

Sometimes a new machine gets added while the old one is still live and 
eventually gets renamed/readdressed when the old one has supplied its 
data to the new one and is turned off for good, but those keys remain.

Case in point, demoing side effects, I had a pair of ark shoeboxes 
running cnc machines in the garage and they started to fail a year ago 
so I bought 4 off-lease dell 7010's with 4 core i5's and 4 gigs of ram 
as thats a great plenty to run LinuxCNC. No drives, no winders licence. 
Cheap that way.

The old ark's with d525mw mobos were so noisy I had to be within 10 feet 
of the garage door motor to run it with a pocket pad.  After replacing 
the old arks with the dells, all with SSD's now, I found my pocket pad 
could run it from 80+ feet away.  The Dells were that much quieter. But 
they run 24/7 and I am seeing a rise in my electric bill from all those 
old i5's. But one got dedicated to running a 3d printer so got its dram 
filled up and its been shut down and rebooted a couple hundred times 
since with no problems in its SDD so I may start shutting them down but 
then when do I turn amanda loose to back them up? She doesn't like her 
schedule to be disturbed.

If I live long enough, I'm 86 now, I may convert them all to being run 
with rpi4's. Draws about 25 watts with its monitor, but runs a 4kw 
machine when LinuxCNC is running as the machines power is 100% 
controlled by LinuxCNC. And the rpi4 has more than enough giddyup to run 
LinuxCNC well. An rpi3 can do it too, but its being pushed. Part of that 
holdup is the cost of the interfacing to the pi's, over $200 a copy. 4 
mesa cards involved per copy.

Thanks for the instructs Dan, recipe printed, I'll see about doing the 
cleanup one machine at a time.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#236227

On Sunday 20 June 2021 10:21:52 Dan Ritter wrote:

> Gene Heskett wrote:
> > I'd like to pleaed for a new apt-key, one that would survey the
> > existing list, and on finding a key that is expired or is no longer
> > associated, offer the option of removing it, or refreshiing it.
> >
> > I have up to 7 machines on my local network, usually accessed by
> > some ssh/sshfs variation, but my current keyring since I'm first
> > user, probably has 30 some keys, many of which are useless as the
> > target machine has been changed by a new machine and a new bare
> > metal install.
>
> This is ssh key management, not apt key management. apt key
> things are for trusting package repositories.

okay, but
>
> Here's what you should do:
>
> 1. create a new ssh keypair on your main machine:
>     ssh-keygen -t rsa -b 4096 -f gene2021

Done. generated /home/gene/gene2021 and /home/gene/gene2021.pub

> 2. for each $targetmachine in your 7 machines, do this:
>     - ssh $targetmachine
>     - mv ~/.ssh/authorized_keys ~/.ssh/authorized_keys_old

4 of the 6 machines have no .ssh directory in /home/gene. ssh may have 
had to be installed after the bare metal install of debian 10 using the 
linuxcnc install cd. sshfs and its deps sure had to be after the first 
reboot. I'll go bug the LinuxCNC install spinners, been meaning to do it 
for months.

Is it sufficient to create that directory, and 
touch .ssh/authorized_keys?

Also, the main machine, this one is still on stretch. With 310 gb used of 
a 2T spinning rust drive as /. I have a 500 gb samsung SSD, but haven't 
found a round-tuit cuz I'd probably wear out the SSD until I get at 
least a 1T SSD I can afford.  Thats getting closer though. But it will 
not happen when I am in the middle of designing and building a new, 
smaller harmonic drive for one of my cnc machines.

>     - don't close that terminal
>     - open a new terminal and make sure you can ssh in by
>       password, then
>     - ssh-copy-id gene2021 $targetmachine
>     - make sure you can ssh in with the gene2021 key:
>       ssh -i gene2021 $targetmachine
>     - if it's good, close both terminals and go on to the next
>       $targetmachine
>
> 3. clean up: remove keys in ~/.ssh/  that aren't gene2021 and
>    aren't useful otherwise.
>
> Now you have one known good keypair that lets you in to all
> seven machines without a password, and you can use a password as
> fallback.
>
> -dsr-


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#236228

[Multipart message — attachments visible in raw view] — view raw

On Sun, Jun 20, 2021 at 12:57:10PM -0400, Gene Heskett wrote:

[...]

> Is it sufficient to create that directory, and 
> touch .ssh/authorized_keys?

Creating the directory should be enough: ssh-copy-id will
take care of making (or overwriting) the file.

You'll want to make sure the SSH server package is installed:
openssh-server.

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#236230

On Sun, Jun 20, 2021 at 03:00:20PM -0400, Dan Ritter wrote:
> The directory can just be created, and then the perms need to be
> 
> chmod 600 ~/.ssh

700, sir.

[toc] | [prev] | [next] | [standalone]

#236232

Greg Wooledge wrote: 
> On Sun, Jun 20, 2021 at 03:00:20PM -0400, Dan Ritter wrote:
> > The directory can just be created, and then the perms need to be
> > 
> > chmod 600 ~/.ssh
> 
> 700, sir.

Thank you.

-dsr-

[toc] | [prev] | [next] | [standalone]

#236231

Gene Heskett wrote: 
> On Sunday 20 June 2021 10:21:52 Dan Ritter wrote:
> 
> > Gene Heskett wrote:
> > > I'd like to pleaed for a new apt-key, one that would survey the
> > > existing list, and on finding a key that is expired or is no longer
> > > associated, offer the option of removing it, or refreshiing it.
> > >
> > > I have up to 7 machines on my local network, usually accessed by
> > > some ssh/sshfs variation, but my current keyring since I'm first
> > > user, probably has 30 some keys, many of which are useless as the
> > > target machine has been changed by a new machine and a new bare
> > > metal install.
> >
> > This is ssh key management, not apt key management. apt key
> > things are for trusting package repositories.
> 
> okay, but
> >
> > Here's what you should do:
> >
> > 1. create a new ssh keypair on your main machine:
> >     ssh-keygen -t rsa -b 4096 -f gene2021
> 
> Done. generated /home/gene/gene2021 and /home/gene/gene2021.pub
> 
> > 2. for each $targetmachine in your 7 machines, do this:
> >     - ssh $targetmachine
> >     - mv ~/.ssh/authorized_keys ~/.ssh/authorized_keys_old
> 
> 4 of the 6 machines have no .ssh directory in /home/gene. ssh may have 
> had to be installed after the bare metal install of debian 10 using the 
> linuxcnc install cd. sshfs and its deps sure had to be after the first 
> reboot. I'll go bug the LinuxCNC install spinners, been meaning to do it 
> for months.
> 
> Is it sufficient to create that directory, and 
> touch .ssh/authorized_keys?

The directory can just be created, and then the perms need to be

chmod 600 ~/.ssh

authorized_keys will be created by ssh-copy-id.

> Also, the main machine, this one is still on stretch. With 310 gb used of 

All of these commands work on stretch and later.

-dsr-

[toc] | [prev] | [next] | [standalone]

#236237

On Sun, Jun 20, 2021 at 10:21:52AM -0400, Dan Ritter wrote:
>This is ssh key management, not apt key management. apt key
>things are for trusting package repositories.
...
>Here's what you should do:

Kindly change the Subject: when you change the subject.

-- 
Please do not CC me for listmail.

👱🏻	Jonathan Dowland
✎	 jmtd@debian.org
🔗	https://jmtd.net

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web