Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[gentoo-user] All Gentoo signing key expired and no way to fix it

694 views
Skip to first unread message

gevisz

unread,
Jul 3, 2018, 3:50:03 AM7/3/18
to
Just today I have tried emerge-webrsync and got
to the following endless circle:

Fetching most recent snapshot ...
Trying to retrieve 20180702 snapshot from http://mirror.netcologne.de/gentoo ...
Fetching file portage-20180702.tar.xz.md5sum ...
Fetching file portage-20180702.tar.xz.gpgsig ...
Fetching file portage-20180702.tar.xz ...
Checking digest ...
Checking signature ...
gpg: Signature made Tue Jul 3 03:51:21 2018 EEST
gpg: using RSA key E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250
gpg: Good signature from "Gentoo Portage Snapshot Signing Key
(Automated Signing Key)" [expired]
gpg: Note: This key has expired!
Primary key fingerprint: DCD0 5B71 EAB9 4199 527F 44AC DB6B 8C1F 96D8 BF6D
Subkey fingerprint: E1D6 ABB6 3BFC FB4B A02F DF1C EC59 0EEA C918 9250
Fetching file portage-20180702.tar.bz2.md5sum ...
Fetching file portage-20180702.tar.bz2.gpgsig ...
Fetching file portage-20180702.tar.bz2 ...
Checking digest ...
Checking signature ...
gpg: Signature made Tue Jul 3 03:51:20 2018 EEST
gpg: using RSA key E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250
gpg: Good signature from "Gentoo Portage Snapshot Signing Key
(Automated Signing Key)" [expired]
gpg: Note: This key has expired!
Primary key fingerprint: DCD0 5B71 EAB9 4199 527F 44AC DB6B 8C1F 96D8 BF6D
Subkey fingerprint: E1D6 ABB6 3BFC FB4B A02F DF1C EC59 0EEA C918 9250
Fetching file portage-20180702.tar.gz.md5sum ...

The following command showed that all Gentoo signing keys in my system expired:

# gpg --homedir /var/lib/gentoo/gkeys/keyrings/gentoo/release
--with-fingerprint --list-keys
/var/lib/gentoo/gkeys/keyrings/gentoo/release/pubring.gpg
---------------------------------------------------------
pub rsa4096 2014-10-03 [C] [expired: 2017-09-17]
D2DE 1DBB A0F4 3EBA 341B 97D8 8255 33CB F6CD 6C97
uid [ expired] Gentoo-keys Team <gk...@gentoo.org>

pub dsa1024 2004-07-20 [SC] [expired: 2018-07-01]
D99E AC73 79A8 50BC E47D A5F2 9E64 38C8 1707 2058
uid [ expired] Gentoo Linux Release Engineering (Gentoo
Linux Release Signing Key) <rel...@gentoo.org>

pub rsa4096 2011-11-25 [C] [expired: 2018-07-01]
DCD0 5B71 EAB9 4199 527F 44AC DB6B 8C1F 96D8 BF6D
uid [ expired] Gentoo Portage Snapshot Signing Key
(Automated Signing Key)

pub rsa4096 2009-08-25 [SC] [expired: 2017-08-25]
13EB BDBE DE7A 1277 5DFD B1BA BB57 2E0E 2D18 2910
uid [ expired] Gentoo Linux Release Engineering (Automated
Weekly Release Key) <rel...@gentoo.org>


Trying to renew them manually with the following commands does not help:

# gpg --keyserver hkps.pool.sks-keyservers.net --recv-keys 0x825533CBF6CD6C97
gpg: key 825533CBF6CD6C97: 2 signatures not checked due to missing keys
gpg: key 825533CBF6CD6C97: public key "Gentoo-keys Team
<gk...@gentoo.org>" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: imported: 1
# gpg --keyserver hkps.pool.sks-keyservers.net --recv-keys 0xDB6B8C1F96D8BF6D
gpg: key DB6B8C1F96D8BF6D: 14 signatures not checked due to missing keys
gpg: key DB6B8C1F96D8BF6D: public key "Gentoo Portage Snapshot Signing
Key (Automated Signing Key)" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: imported: 1
# gpg --keyserver hkps.pool.sks-keyservers.net --recv-keys 0x9E6438C817072058
gpg: key 9E6438C817072058: 83 signatures not checked due to missing keys
gpg: key 9E6438C817072058: public key "Gentoo Linux Release
Engineering (Gentoo Linux Release Signing Key) <rel...@gentoo.org>"
imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: imported: 1
# gpg --keyserver hkps.pool.sks-keyservers.net --recv-keys 0xBB572E0E2D182910
gpg: key BB572E0E2D182910: 10 signatures not checked due to missing keys
gpg: key BB572E0E2D182910: 1 bad signature
gpg: key BB572E0E2D182910: public key "Gentoo Linux Release
Engineering (Automated Weekly Release Key) <rel...@gentoo.org>"
imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: imported: 1

Here https://wiki.gentoo.org/wiki/Handbook:AMD64/Working/Features#Fetching_files
has been said the following:

If any of the keys installed from app-crypt/gentoo-keys should expire,
run gkeys from app-crypt/gkeys to refresh them from the key server:
root #emerge --ask app-crypt/gkeys
root #gkeys refresh-key -C gentoo

but gkeys are not stable in my architeture as it follows from the following:

$ eix gkeys
* app-crypt/gkeys
Available versions: ~0.2 **9999 {PYTHON_TARGETS="python2_7
python3_4 python3_5 python3_6"}
Homepage: https://wiki.gentoo.org/wiki/Project:Gentoo-keys
Description: An OpenPGP/GPG key management tool and python libs

* app-crypt/gkeys-gen
Available versions: ~0.2 **9999 {PYTHON_TARGETS="python2_7
python3_4 python3_5 python3_6"}
Homepage: https://wiki.gentoo.org/wiki/Project:Gentoo-keys
Description: Tool for generating OpenPGP/GPG keys using a
specifications file

Mick

unread,
Jul 3, 2018, 4:20:03 AM7/3/18
to
This package update came up yesterday:

app-crypt/openpgp-keys-gentoo-release-20180702

which as I understand will update the portage keys accordingly but I don't use
webrsync to know if it applies the same way.
--
Regards,
Mick
signature.asc

Arve Barsnes

unread,
Jul 3, 2018, 5:00:03 AM7/3/18
to
On 3 July 2018 at 09:48, gevisz <gev...@gmail.com> wrote:
> Trying to renew them manually with the following commands does not help:
>
> # gpg --keyserver hkps.pool.sks-keyservers.net --recv-keys 0x825533CBF6CD6C97

It solved itself for me after running
gpg --homedir /var/lib/gentoo/gkeys/keyrings/gentoo/release --refresh-keys

Cheers,
Arve

Mick

unread,
Jul 3, 2018, 5:00:03 AM7/3/18
to
Hmm ...

# gpg --homedir /var/lib/gentoo/gkeys/keyrings/gentoo/release --refresh-keys
gpg: keyblock resource '/var/lib/gentoo/gkeys/keyrings/gentoo/release/
pubring.kbx': No such file or directory

:-/

--
Regards,
Mick
signature.asc

Arve Barsnes

unread,
Jul 3, 2018, 5:50:02 AM7/3/18
to
On 3 July 2018 at 10:55, Mick <michael...@gmail.com> wrote:
> # gpg --homedir /var/lib/gentoo/gkeys/keyrings/gentoo/release --refresh-keys
> gpg: keyblock resource '/var/lib/gentoo/gkeys/keyrings/gentoo/release/
> pubring.kbx': No such file or directory
>
> :-/

Hmm...

I don't have this file either, but had no problems.

Virgil Dupras

unread,
Jul 3, 2018, 6:40:02 AM7/3/18
to
Are you, by any chance, running this command through something like lxc-attach or ssh? I had the exact same problem two days ago and it turned out to be something about the environment being passed to the remote system. Sourcing /etc/profile did the trick.

Regards,
Virgil

gevisz

unread,
Jul 3, 2018, 6:50:03 AM7/3/18
to
Too late: Gentoo signing keys expired on 1 July 2018.
So, no way to update portage tree on 2 July 2018. :(

gevisz

unread,
Jul 3, 2018, 6:50:03 AM7/3/18
to
Thank you for your reply, but running the command above have not
solved my problem:

# gpg --homedir /var/lib/gentoo/gkeys/keyrings/gentoo/release --refresh-keys
gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net
gpg: key 825533CBF6CD6C97: 2 signatures not checked due to missing keys
gpg: key 825533CBF6CD6C97: "Gentoo-keys Team <gk...@gentoo.org>" 5 new
signatures
gpg: key 825533CBF6CD6C97: "Gentoo-keys Team <gk...@gentoo.org>" 2 new subkeys
gpg: Total number processed: 1
gpg: new subkeys: 2
gpg: new signatures: 5
gpg: no ultimately trusted keys found

# gpg --homedir /var/lib/gentoo/gkeys/keyrings/gentoo/release
--with-fingerprint --list-keys
/var/lib/gentoo/gkeys/keyrings/gentoo/release/pubring.gpg
---------------------------------------------------------
pub rsa4096 2014-10-03 [C] [expires: 2019-06-29]
D2DE 1DBB A0F4 3EBA 341B 97D8 8255 33CB F6CD 6C97
uid [ unknown] Gentoo-keys Team <gk...@gentoo.org>
sub rsa4096 2014-10-03 [S] [expires: 2018-12-31]
sub rsa4096 2018-06-29 [S] [expires: 2018-12-26]

pub dsa1024 2004-07-20 [SC] [expired: 2018-07-01]
D99E AC73 79A8 50BC E47D A5F2 9E64 38C8 1707 2058
uid [ expired] Gentoo Linux Release Engineering (Gentoo
Linux Release Signing Key) <rel...@gentoo.org>

pub rsa4096 2011-11-25 [C] [expired: 2018-07-01]
DCD0 5B71 EAB9 4199 527F 44AC DB6B 8C1F 96D8 BF6D
uid [ expired] Gentoo Portage Snapshot Signing Key
(Automated Signing Key)

pub rsa4096 2009-08-25 [SC] [expired: 2017-08-25]
13EB BDBE DE7A 1277 5DFD B1BA BB57 2E0E 2D18 2910
uid [ expired] Gentoo Linux Release Engineering (Automated
Weekly Release Key) <rel...@gentoo.org>

# emerge-webrsync

gevisz

unread,
Jul 3, 2018, 7:10:02 AM7/3/18
to
2018-07-03 13:41 GMT+03:00 gevisz <gev...@gmail.com>:
> 2018-07-03 11:10 GMT+03:00 Mick <michael...@gmail.com>:
>> On Tuesday, 3 July 2018 08:48:02 BST gevisz wrote:
...
>>
>> This package update came up yesterday:
>>
>> app-crypt/openpgp-keys-gentoo-release-20180702
>>
>
> Too late: Gentoo signing keys expired on 1 July 2018.
> So, no way to update portage tree on 2 July 2018. :(

And only after updating the portage tree, I have got
app-crypt/openpgp-keys-gentoo-release-20180702.

Why not to put new openpgp-keys-gentoo-release
into the portage tree BEFORE all existing Gentoo
singing keys expire?

# emerge --update --deep --with-bdeps=y --newuse --backtrack=120 --ask world

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild U ] dev-util/gperf-3.1 [3.0.4]
[ebuild U ] app-crypt/openpgp-keys-gentoo-release-20180702 [20180530]
[ebuild NS ] sys-kernel/gentoo-sources-4.14.52 [4.9.95]
USE="-build -experimental -symlink"
[ebuild U ] dev-python/pydot-1.2.3 [1.0.28-r2] USE="{-test%}"
PYTHON_TARGETS="python3_5%* -python3_4% -python3_6%"

Would you like to merge these packages? [Yes/No] y

...

gevisz

unread,
Jul 3, 2018, 7:10:03 AM7/3/18
to
No, I do it on my desktop staying just in front of me.
So, no need for ssh (and I do not know what lxc-attach is at all).

Still, sourcing /etc/profile somehow helped:

# emerge-webrsync
Fetching most recent snapshot ...
Trying to retrieve 20180702 snapshot from http://mirror.netcologne.de/gentoo ...
Fetching file portage-20180702.tar.xz.md5sum ...
Fetching file portage-20180702.tar.xz.gpgsig ...
Fetching file portage-20180702.tar.xz ...
Checking digest ...
Checking signature ...
gpg: Signature made Tue Jul 3 03:51:21 2018 EEST
gpg: using RSA key E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250
gpg: Good signature from "Gentoo Portage Snapshot Signing Key
(Automated Signing Key)" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: DCD0 5B71 EAB9 4199 527F 44AC DB6B 8C1F 96D8 BF6D
Subkey fingerprint: E1D6 ABB6 3BFC FB4B A02F DF1C EC59 0EEA C918 9250
Getting snapshot timestamp ...
Syncing local tree ...

Number of files: 161,691 (reg: 134,254, dir: 27,437)
Number of created files: 308 (reg: 301, dir: 7)
Number of deleted files: 272 (reg: 268, dir: 4)
Number of regular files transferred: 1,462
Total file size: 218.08M bytes
Total transferred file size: 10.83M bytes
Literal data: 10.83M bytes
Matched data: 0 bytes
File list size: 589.73K
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 11.76M
Total bytes received: 69.61K

sent 11.76M bytes received 69.61K bytes 463.97K bytes/sec
total size is 218.08M speedup is 18.43
Cleaning up ...

Rich Freeman

unread,
Jul 3, 2018, 7:50:02 AM7/3/18
to
On Tue, Jul 3, 2018 at 7:06 AM gevisz <gev...@gmail.com> wrote:
>
> Why not to put new openpgp-keys-gentoo-release
> into the portage tree BEFORE all existing Gentoo
> singing keys expire?
>

My guess is that it was an oversight.

I note that emerge --sync seems to update keys from the keyserver
automatically, and thus it didn't report any errors syncing for me.
On the other hand, I believe it will leave /usr/portage compromised if
an error is detected, so if you don't actually catch the error it
throws you can still be harmed. I assume webrsync won't do that, but
I haven't checked (the repository I use isn't available to webrsync as
far as I'm aware).

Improving signature checking is an area of recent interest, as you can
imagine, so I suspect these will improve.

--
Rich

gevisz

unread,
Jul 3, 2018, 8:50:03 AM7/3/18
to
2018-07-03 14:47 GMT+03:00 Rich Freeman <ri...@gentoo.org>:
> On Tue, Jul 3, 2018 at 7:06 AM gevisz <gev...@gmail.com> wrote:
>>
>> Why not to put new openpgp-keys-gentoo-release
>> into the portage tree BEFORE all existing Gentoo
>> singing keys expire?
>>
>
> My guess is that it was an oversight.
>
> I note that emerge --sync seems to update keys from the keyserver
> automatically, and thus it didn't report any errors syncing for me.
> On the other hand, I believe it will leave /usr/portage compromised if
> an error is detected, so if you don't actually catch the error it
> throws you can still be harmed. I assume webrsync won't do that, but
> I haven't checked (the repository I use isn't available to webrsync as
> far as I'm aware).

emerge-webrsync do check gpg Gentoo signitures, if webrsync-gpg
feature is enabled in /etc/portage/make.conf, but it cannot do so, if
all Gentoo signitures expired, as it was the case after 1 July 2018.

Rich Freeman

unread,
Jul 3, 2018, 9:10:03 AM7/3/18
to
I know it checks sigs. I was assuming that it won't actually
overwrite a good /usr/portage with a bad one if the verification
fails.

emerge --sync, with git at least, overwrites /usr/portage in place and
so it will leave it in a bad state if verification fails.

--
Rich

Mart Raudsepp

unread,
Jul 3, 2018, 9:30:03 AM7/3/18
to
Ühel kenal päeval, T, 03.07.2018 kell 14:00, kirjutas gevisz:
> Are you, by any chance, running this command through something like
> > lxc-attach or ssh?
> > I had the exact same problem two days ago and it turned out to be
> > something about the
> > environment being passed to the remote system. Sourcing
> > /etc/profile did the trick.
>
> No, I do it on my desktop staying just in front of me.
> So, no need for ssh (and I do not know what lxc-attach is at all).
>
> Still, sourcing /etc/profile somehow helped:

How do you obtain root privileges for the command?

If you use su, you should be using "su -" (or "su -l" or "su --login"),
not "su".

If you use sudo, you might need to pass -i (--login) option to it.

And I mean that in general, not just for overcoming this error.


Mart
signature.asc

Arve Barsnes

unread,
Jul 3, 2018, 11:00:04 AM7/3/18
to
On 3 July 2018 at 15:22, Mart Raudsepp <le...@gentoo.org> wrote:
> How do you obtain root privileges for the command?
>
> If you use su, you should be using "su -" (or "su -l" or "su --login"),
> not "su".

I did not need to do so to make this work.

It all depends on the environment you start out with I guess.

R0b0t1

unread,
Jul 3, 2018, 5:00:04 PM7/3/18
to
It looks like you resolved the issue. I had to refresh the keys multiple times.

gevisz

unread,
Jul 4, 2018, 12:30:03 PM7/4/18
to
2018-07-03 16:04 GMT+03:00 Rich Freeman <ri...@gentoo.org>:
> On Tue, Jul 3, 2018 at 8:44 AM gevisz <gev...@gmail.com> wrote:
>>
>> 2018-07-03 14:47 GMT+03:00 Rich Freeman <ri...@gentoo.org>:
>> > On Tue, Jul 3, 2018 at 7:06 AM gevisz <gev...@gmail.com> wrote:
>> >>
>> >> Why not to put new openpgp-keys-gentoo-release
>> >> into the portage tree BEFORE all existing Gentoo
>> >> singing keys expire?
>> >>
>> >
>> > My guess is that it was an oversight.
>> >
>> > I note that emerge --sync seems to update keys from the keyserver
>> > automatically, and thus it didn't report any errors syncing for me.
>> > On the other hand, I believe it will leave /usr/portage compromised if
>> > an error is detected, so if you don't actually catch the error it
>> > throws you can still be harmed. I assume webrsync won't do that, but
>> > I haven't checked (the repository I use isn't available to webrsync as
>> > far as I'm aware).
>>
>> emerge-webrsync do check gpg Gentoo signitures, if webrsync-gpg
>> feature is enabled in /etc/portage/make.conf, but it cannot do so, if
>> all Gentoo signitures expired, as it was the case after 1 July 2018.
>>
>
> I know it checks sigs. I was assuming that it won't actually
> overwrite a good /usr/portage with a bad one if the verification
> fails.

Yes. I think it the only acceptable behavior.

> emerge --sync, with git at least, overwrites /usr/portage in place and
> so it will leave it in a bad state if verification fails.

It sounds really aweful.
I did not know this as I always used only emerge-webrsync.

Rich Freeman

unread,
Jul 4, 2018, 1:40:03 PM7/4/18
to
Yes. I do have scripts set to abort if it fails and I should notice.
But, this isn't really viewed as acceptable by anybody - there just
hasn't been a more complete solution devised.

Part of the issue is that I think portage just has git do a pull
in-place which just overwrites everything, and then portage does the
signature check after that.

I wonder if we can have portage instead do a fetch, then do the
verification of HEAD, and then if it passes do a checkout. That will
still leave you with invalid data in the git history, but it won't
actually be checked out, so at least emerge won't be seeing it.

--
Rich

gevisz

unread,
Jul 4, 2018, 1:40:03 PM7/4/18
to
2018-07-03 16:22 GMT+03:00 Mart Raudsepp <le...@gentoo.org>:
> Ühel kenal päeval, T, 03.07.2018 kell 14:00, kirjutas gevisz:
>> Are you, by any chance, running this command through something like
>> > lxc-attach or ssh?
>> > I had the exact same problem two days ago and it turned out to be
>> > something about the
>> > environment being passed to the remote system. Sourcing
>> > /etc/profile did the trick.
>>
>> No, I do it on my desktop staying just in front of me.
>> So, no need for ssh (and I do not know what lxc-attach is at all).
>>
>> Still, sourcing /etc/profile somehow helped:
>
> How do you obtain root privileges for the command?

su

> If you use su, you should be using "su -" (or "su -l" or "su --login"),
> not "su".

I have used only "su" for already 3 years, since switched to Gentoo
from Ubuntu and never had any problems with it.

Could you explain a little bit more why "su -" should be used instead.

From the man page I've got the following:

-, -l, --login
Provide an environment similar to what the user would expect had
the user logged in directly.

But I cannot see why I need the original root environment,
especially if I never set it up.

> If you use sudo, you might need to pass -i (--login) option to it.

I hate using sudo since I have been forced to use it in Ubuntu.

gevisz

unread,
Jul 4, 2018, 1:50:03 PM7/4/18
to
2018-07-03 23:55 GMT+03:00 R0b0t1 <r03...@gmail.com>:
>
> It looks like you resolved the issue.

Yes.

> I had to refresh the keys multiple times.

I also refreshed them many times but it "shot" only after sourcing /etc/profile.

Jack

unread,
Jul 4, 2018, 2:10:03 PM7/4/18
to
On 2018.07.04 13:38, gevisz wrote:
> 2018-07-03 16:22 GMT+03:00 Mart Raudsepp <le...@gentoo.org>:
> > Ühel kenal päeval, T, 03.07.2018 kell 14:00, kirjutas gevisz:
>>> Are you, by any chance, running this command through something like
>>> lxc-attach or ssh?
>>>> I had the exact same problem two days ago and it turned out to be
>>>> something about the environment being passed to the remote system.
>>>> Sourcing /etc/profile did the trick.
>>> No, I do it on my desktop staying just in front of me. So, no need
>>> for ssh (and I do not know what lxc-attach is at all).
> >>
> >> Still, sourcing /etc/profile somehow helped:
> >
> > How do you obtain root privileges for the command?
>
> su
>
>> If you use su, you should be using "su -" (or "su -l" or "su
>> --login"), not "su".
>
> I have used only "su" for already 3 years, since switched to Gentoo
> from Ubuntu and never had any problems with it.
>
> Could you explain a little bit more why "su -" should be used instead.
It's not so much needing the root environment, it's that sometimes
things in your own environment cause problems if not removed when
emerge runs. There is another recent thread about emerge (nodejs)
failing because of sandbox violations due to some XDG variable causing
an install script to try writing to somewhere it would not have it the
environment had been properly sanitized. Note I consider this a
general precaution, it may or may not be relevant for the subject of
this thread. The problems caused by this issue are indeed infrequent
and sporadic, so it's not surprising that you have not run into any of
them. It seems to be related to the details in some ebuilds.

> From the man page I've got the following:
>
> -, -l, --login
> Provide an environment similar to what the user would expect
> had the user logged in directly.
>
> But I cannot see why I need the original root environment, especially
> if I never set it up.
That's partly the point - the root environment is generally much more
empty than that of your usual user.

> > If you use sudo, you might need to pass -i (--login) option to it.
>
> I hate using sudo since I have been forced to use it in Ubuntu.
I almost never used sudo when I used Ubuntu. I used su or logged in as
root when necessary.
>

Jack

gevisz

unread,
Jul 4, 2018, 2:50:03 PM7/4/18
to
Ok, got it. Thank you for the explanation.

>> From the man page I've got the following:
>>
>> -, -l, --login
>> Provide an environment similar to what the user would expect had
>> the user logged in directly.
>>
>> But I cannot see why I need the original root environment, especially if I
>> never set it up.
>
> That's partly the point - the root environment is generally much more empty
> than that of your usual user.
>
>> > If you use sudo, you might need to pass -i (--login) option to it.
>>
>> I hate using sudo since I have been forced to use it in Ubuntu.
>
> I almost never used sudo when I used Ubuntu. I used su or logged in as root
> when necessary.

It is quite strange because, when I used Ubuntu, it had no root account,
and so, everybody was forced to use sudo to get root privileges.

Ian Zimmerman

unread,
Jul 4, 2018, 3:10:03 PM7/4/18
to
On 2018-07-04 21:40, gevisz wrote:

> It is quite strange because, when I used Ubuntu, it had no root
> account, and so, everybody was forced to use sudo to get root
> privileges.

Of course there is a root account. It is just blocked by default from
accepting logins. You can simply run "passwd root" (as root) to change
that.

Another way (and this is what I use now on gentoo) is ssh root@localhost.

--
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

Rich Freeman

unread,
Jul 5, 2018, 9:30:03 AM7/5/18
to
On Wed, Jul 4, 2018 at 1:34 PM Rich Freeman <ri...@gentoo.org> wrote:
>
> I wonder if we can have portage instead do a fetch, then do the
> verification of HEAD, and then if it passes do a checkout. That will
> still leave you with invalid data in the git history, but it won't
> actually be checked out, so at least emerge won't be seeing it.
>

Kudos to zmedico on the quick patch:
https://github.com/gentoo/portage/pull/332/commits/74c3b10dba60bcb096404c6aca148b9ae7a9a80b

I'm sure it will be a bit before it is released, but this should make
git syncs much more secure.

--
Rich

Grant Edwards

unread,
Jul 5, 2018, 10:10:03 AM7/5/18
to
Nonsense.

Ubuntu has always had a root account, and still does [see below]. By
default the installer doesn't set up a password for the root account,
but that's trivial to do after the install is finished.




$ cat /etc/os-release

NAME="Ubuntu"
VERSION="18.04 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic

$ grep root /etc/passwd
root:x:0:0:root:/root:/bin/bash

--
Grant Edwards grant.b.edwards Yow! PARDON me, am I
at speaking ENGLISH?
gmail.com

Tom H

unread,
Jul 6, 2018, 8:00:03 PM7/6/18
to
It's more to protect from user envvars leaking into root's
environment. That's why "service(8)" resets the environment (and then
sets some, like PATH) on Linux and {Free,Net}BSD.

I've seen a daemon log in german because a colleague simply used "su"
to restart it (without using "service").


>> If you use sudo, you might need to pass -i (--login) option to it.
>
> I hate using sudo since I have been forced to use it in Ubuntu.

Ubuntu defaults to "sudo" but doesn't force you to use it! If you
prefer "su", set a root password.

Tom H

unread,
Jul 6, 2018, 8:10:03 PM7/6/18
to
On Wed, Jul 4, 2018 at 5:43 PM gevisz <gev...@gmail.com> wrote:
>
> but it "shot" only after sourcing /etc/profile.

Which is what "su -l" does.
0 new messages