New Raspbian release "2016-11-25"

[spl23]

OK, I know what is going wrong - the locking of the pi user password is changing the format of the relevant line in the shadow file such that the salt can't be read from it; as a result mkpasswd fails, and a false positive is generated. That should be fairly easy to fix - if I get something that looks as if it works, I'll drop you a PM and you can try it.

[HawaiianPi]

Just to be 100% sure - can you please tell me what "mkpasswd aaa" returns on your system?

Seems to return random junk each time I run it.

Code: Select all

~ $ mkpasswd aaa
9ji5L6x49bFxI
~ $ mkpasswd aaa
Ma6yyywOUJOaQ
~ $ mkpasswd aaa
93Pq8KOCEadqk
~ $ 

Apologies for the inconvenience - as with all such changes, there's no way we can test every single configuration that users will have before release, so there will always be a few cases where a system is in a state we hadn't anticipated. We'll try and get a fix out for this asap.

I totally understand. Sorry if I seemed a bit grumpy, I just haven't had my morning coffee yet.

Ah - I think I know what is going wrong - the locking of the pi user password is changing the format of the relevant line in the shadow file such that the salt can't be read from it; as a result mkpasswd fails, and a false positive is generated. That should be fairly easy to fix - if I get something that looks as if it works, I'll drop you a PM and you can try it.

Awesome! Be happy to test it.

I did re-enable the pi account, logged in as pi and changed the password, and there was no warning after I rebooted.

Then I locked pi and rebooted, and yup, the warning was back!

[Martin Frezman]

One more thing about this:

Suppose you've done a "dist-upgrade" and gotten the latest stuff and you now have the file: /etc/profile.d/sshpasswd.sh
on your system, so that every time you log in as pi, you get this little missive from the system.

What is the approved way to disable this? Is it OK to just 'rm' the file, or is there some systemd/sysctl command to use instead?

Note, BTW, that even if you have changed pi's pw, running this script still takes some time; I can see that it takes longer to login than it used to.

[ShiftPlusOne]

Yes, removing the file is the way to go, if you would like to disable it.

[PeterO]

Apologies for the inconvenience - as with all such changes, there's no way we can test every single configuration that users will have before release, so there will always be a few cases where a system is in a state we hadn't anticipated. We'll try and get a fix out for this asap.

Do you have a team of tame beta testers from the community ?

PeterO

[B.Goode]

Apologies for the inconvenience - as with all such changes, there's no way we can test every single configuration that users will have before release, so there will always be a few cases where a system is in a state we hadn't anticipated. We'll try and get a fix out for this asap.

Do you have a team of tame beta testers from the community ?

PeterO

A previous related response indicates that community involvement is thought to be already in place by virtue of committing developments to a github repository: viewtopic.php?f=66&t=166984&start=25#p1075374

[jojopi]

Note, BTW, that even if you have changed pi's pw, running this script still takes some time; I can see that it takes longer to login than it used to.

Amusingly, it does all the slow stuff before the test for sshd that inhibits the warning. (Is it a defect that it does not check whether sshd accepts passwords, or is it a defect that it assumes sshd is the only service that can?)

If anyone uses ksh, they get an error. Both the script and its output are ugly in an 80 column window. The message confusingly tells the user to login as 'pi', when most likely that is exactly what they have just done.

I still think we should look at not setting a default password, rather than only (unreliably) nagging users to change it.

[PeterO]

A previous related response indicates that community involvement is thought to be already in place by virtue of committing developments to a github repository: viewtopic.php?f=66&t=166984&start=25#p1075374

Yet the last few days since the release of latest version clearly show that that is not sufficient to get the changes tested before they are released. It needs a simple "here is the latest beta to be tested" approach rather than expecting testers to track all the changes on github and apply them themselves. And getting testers to apply changes to their own systems means they will not be testing the final released versions of everything because their systems may have already been patched or upgraded.

If you want people to test something for you it has to be made as simple as possible for them otherwise you won't get the interest you want.

PeterO

[DougieLawson]

I discovered more breakage in 2016-11-25.

There's a new /etc/profile.d/sshpasswd.sh script that includes a sudo command (trying to read /etc/shadow). That fails brilliantly if you've removed all the passwordless sudo crap (from /etc/sudoers.d). I been getting some amusing security warning emails.

The RPF foundation folks don't seem to have grasped the concept of "real world security" - can they stop putting new junk in my /etc directory.

Tell me what's happening when I run apt-get -y update or apt-get -y dist-upgrade which includes security changes. Let me choose whether I want to install that crap that's going to break my system.

[B.Goode]

@Peter won't want or need my support, but "+1" to his comment.

I hope it is clear from my linked suggestion earlier in the thread that I think the community could have a role to play here. But the RPF have repeatedly shown that their opinion differs...

[ShiftPlusOne]

Note, BTW, that even if you have changed pi's pw, running this script still takes some time; I can see that it takes longer to login than it used to.

Amusingly, it does all the slow stuff before the test for sshd that inhibits the warning. (Is it a defect that it does not check whether sshd accepts passwords, or is it a defect that it assumes sshd is the only service that can?)

If anyone uses ksh, they get an error. Both the script and its output are ugly in an 80 column window. The message confusingly tells the user to login as 'pi', when most likely that is exactly what they have just done.

I still think we should look at not setting a default password, rather than only (unreliably) nagging users to change it.

Thanks, that's actually all useful feedback.

[dasmanul]

There's a new /etc/profile.d/sshpasswd.sh script that includes a sudo command (trying to read /etc/shadow). That fails brilliantly if you've removed all the passwordless sudo crap (from /etc/sudoers.d). I been getting some amusing security warning emails.

I've pointed this out in a comment to the Github commit (and in this thread) - the official stance seems to be "this won't affect 99% of users so it's no problem".

[ShiftPlusOne]

There's a new /etc/profile.d/sshpasswd.sh script that includes a sudo command (trying to read /etc/shadow). That fails brilliantly if you've removed all the passwordless sudo crap (from /etc/sudoers.d). I been getting some amusing security warning emails.

I've pointed this out in a comment to the Github commit (and in this thread) - the official stance seems to be "this won't affect 99% of users so it's no problem".

That's not quite the official stance. The official stance is closer to "We know and will fix it in the long term, but right now there is no way around it."

[DougieLawson]

There's a new /etc/profile.d/sshpasswd.sh script that includes a sudo command (trying to read /etc/shadow). That fails brilliantly if you've removed all the passwordless sudo crap (from /etc/sudoers.d). I been getting some amusing security warning emails.

I've pointed this out in a comment to the Github commit (and in this thread) - the official stance seems to be "this won't affect 99% of users so it's no problem".

That's not quite the official stance. The official stance is closer to "We know and will fix it in the long term, but right now there is no way around it."

There's even more reason to warn me when apt-get installs it. I'm not looking at any of that stuff on github. The only bits of Raspberry stuff I look at are kernel, firmware (usually the hexxeh piece) and weather station. So this arrived as a complete surprise (when I started getting security emails from my internet opened machine).

[dasmanul]

That's not quite the official stance. The official stance is closer to "We know and will fix it in the long term, but right now there is no way around it."

Actually, the comments in the Github commit page sounded different to me, but I might of course have misread them. That the blog post announcing the new release doesn't mention the issues also points in a different direction than "we'll fix this eventually" IMHO.

[marioscube]

I would like to thank the incompetents that broke "Booting from USB" with the latest update!

On a perfectly running raspbian system I did:
(sudo) apt-get update
(sudo) apt-get upgrade
..... and then after a restart (I "poweroff" the Pi after using it) ........ NOTHING

I took a spare HD and confirmed this behaviour.

Didn't you test this?

[ShiftPlusOne]

I would like to thank the incompetents that broke "Booting from USB" with the latest update!

On a perfectly running raspbian system I did:
(sudo) apt-get update
(sudo) apt-get upgrade
..... and then after a restart (I "poweroff" the Pi after using it) ........ NOTHING

I took a spare HD and confirmed this behaviour.

Didn't you test this?

Please get your facts straight and try again. You installed EXPERIMENTAL firmware using rpi-update (most likely). That replaces files which are managed by apt. Of course it will get overwritten when the package containing the actual release firmware is updated.

[marioscube]

So you did not test it and did not / forgot to put this in the announcement of a SECURITY update.

But anyway, thank you for clearing up why it did not work.
Just do not update.......

[PeterO]

Please get your facts straight and try again. .

However it is symptomatic of the Foundation having a problem with it's software release/update strategy and its procedures.
Announcing things as experimental (that do work), and that then get broken by future releases (OpenGL driver, USB Booting) is sadly becoming a pattern. It's not the way to encourage people to try out the new features

PeterO

[ShiftPlusOne]

So you did not test it and did not / forgot to put this in the announcement of a SECURITY update.

But anyway, thank you for clearing up why it did not work.
Just do not update.......

This applies to every single firmware update released through apt and there won't be a blog post each time telling rpi-update users how apt works (they should already know).

[B.Goode]

So you did not test it and did not / forgot to put this in the announcement of a SECURITY update.

But anyway, thank you for clearing up why it did not work.
Just do not update.......

This is almost certainly unrelated to the 2016-11-25 release of Raspbian.

I'm pretty sure that if you used the September 'Pixel' release as a base and did the same operation you would get a similar failure. And I'm fairly sure I have seen a warning in the discussion of the beta USB/net booting feature that exactly what you describe was to be expected.

(I sympathise with your frustration, but although I kicked off this thread in some surprise at the content of the release I don't think your issue is really a consequence.)

[marioscube]

@B.Goode

I'm pretty sure that if you used the September 'Pixel' release as a base and did the same operation you would get a similar failure.

Well that's exactly what I did.

Thank you for sympathising, but I'm allready over it now. Somewhat.

However I find it strange that any update (apt-get upgrade) would break USB boot. To enable USB boot no extra raspbian code needs to be installed. It's just a removable setting in a file (/boot/config/txt).

[ShiftPlusOne]

@B.Goode

I'm pretty sure that if you used the September 'Pixel' release as a base and did the same operation you would get a similar failure.

Well that's exactly what I did.

Thank you for sympathising, but I'm allready over it now. Somewhat.

However I find it strange that any update (apt-get upgrade) would break USB boot. To enable USB boot no extra raspbian code needs to be installed. It's just a removable setting in a file (/boot/config/txt).

To enable USB boot, you need special firmware (which was overwritten), so it's not just a config.txt setting.

[DougieLawson]

So you did not test it and did not / forgot to put this in the announcement of a SECURITY update.

But anyway, thank you for clearing up why it did not work.
Just do not update.......

Since you've run BRANCH=next rpi-update to get the USB/PXE bootcode then that MUST be re-run that whenever the apt-get stuff updates the kernel. That's obvious and there's nothing the RPF folks have done wrong with that one. You'll also need to remove /boot/.firmware_revision or rpi-update will terminate without making any updates.

When the USB/PXE bootcode is out of beta and part of the regular mainstream kernel then you may have something to moan about.

[njspix]

So I am using a headless RPi as a Samba server on my local network. I have deleted the pi user (using userdel if I remember correctly). I configured SSH to run on an uncommon port, and use key authentication. I then port-forwarded the machine. A couple of days ago I updated the Pi and when I connected to it this morning (from a remote location) I got the warning message about the pi password being set to default. I panicked and immediately shutdown the pi after logging in.

I'm confused because as far as I know, the pi account doesn't even exist anymore. Is this just a little semantic mix-up, or did the pi account somehow get reinstated? If so, I'm guessing I should assume the machine is compromised?

By the way, RPi is my introduction to Linux. I don't know much...yet. So any advice would be helpful.