New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make the sp_lstchg shadow field reproducible (re. #71) #146

Open
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
3 participants
@lamby
Copy link
Contributor

lamby commented Jan 2, 2019

From #71:

The third field in the /etc/shadow file (sp_lstchg) contains the date of
the last password change expressed as the number of days since Jan 1, 1970.
As this is a relative time, creating a user today will result in:

username:17238:0:99999:7:::
whilst creating the same user tomorrow will result in:

username:17239:0:99999:7:::
This has an impact for the Reproducible Builds[0] project where we aim to
be independent of as many elements the build environment as possible,
including the current date.

This patch changes the behaviour to use the SOURCE_DATE_EPOCH[1]
environment variable (instead of Jan 1, 1970) if valid.

This updated PR adds some missing calls to gettime (). This was originally
filed by Johannes Schauer in Debian as #917773 [2].

[0] https://reproducible-builds.org/
[1] https://reproducible-builds.org/specs/source-date-epoch/
[2] https://bugs.debian.org/917773

Make the sp_lstchg shadow field reproducible (re. #71)
From <#71>:

```
The third field in the /etc/shadow file (sp_lstchg) contains the date of
the last password change expressed as the number of days since Jan 1, 1970.
As this is a relative time, creating a user today will result in:

username:17238:0:99999:7:::
whilst creating the same user tomorrow will result in:

username:17239:0:99999:7:::
This has an impact for the Reproducible Builds[0] project where we aim to
be independent of as many elements the build environment as possible,
including the current date.

This patch changes the behaviour to use the SOURCE_DATE_EPOCH[1]
environment variable (instead of Jan 1, 1970) if valid.
```

This updated PR adds some missing calls to gettime (). This was originally
filed by Johannes Schauer in Debian as #917773 [2].

[0] https://reproducible-builds.org/
[1] https://reproducible-builds.org/specs/source-date-epoch/
[2] https://bugs.debian.org/917773
@hallyn

This comment has been minimized.

Copy link
Contributor

hallyn commented Jan 3, 2019

Is there any security concern here? It seems like the only possible problem would be if a user with no shadow entry called passwd with a future date for SOURCE_DATE_EPOCH.

@lamby

This comment has been minimized.

Copy link
Contributor

lamby commented Jan 3, 2019

What would be the hypothetical attack there, just out of interest?

(re. security, there are other related discussions, possibly from yourself, on this area in the above links IIRC)

@hallyn

This comment has been minimized.

Copy link
Contributor

hallyn commented Jan 4, 2019

The only attack I can imagine is delaying/preventing password aging. But I'm often not very imgaintaive...

@lamby

This comment has been minimized.

Copy link
Contributor

lamby commented Jan 4, 2019

Nor I, alas. :) I don't believe there is an issue, obviously...

@t8m

This comment has been minimized.

Copy link
Contributor

t8m commented Jan 4, 2019

Actually it would be a security issue if user without preexisting shadow entry could prevent password ageing on password change. Although the issue would be fairly low impact one. I'd suggest using secure_getenv() instead of normal getenv() in gettime().

@lamby

This comment has been minimized.

Copy link
Contributor

lamby commented Jan 4, 2019

Good idea re secure_getenv - pushed.

@hallyn

This comment has been minimized.

Copy link
Contributor

hallyn commented Jan 4, 2019

Stupid q - is there any libc which would not provide secure_getenv()? Actually the manpage says it's glibc-specific. Should a dummy helper be added if it's not defined?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment