Hi all,
the openssl will be rebased in Rawhide to 1.1.0 on Monday. There will
be also 1.0.2 compat package (compat-openssl10) so the dependencies are
not broken and Rawhide should be installable. Also things that do not
depend on openssl should be rebuildable without changes.
On the other hand due to the major API changes in 1.1.0 if your package
uses OpenSSL it will not be possible to rebuild it without patching.
Some upstreams already updated their code to work with 1.1.0 so if it
is your case again there might not be any problems rebuilding it.
I will be also working on patching and rebuilding the dependencies
starting with minimal install and expanding to broader installs of
Fedora. However there might be cases where the package is using some
obscure features of the old 1.0.x API and the port might be non-trivial
- I do not expect such packages to be common however cooperation with
the respective package upstream might be needed in such cases.
At worst if the patching of a package is highly non-trivial and the
upstream is not responsive we might have to drop the package from
Fedora.
We do not want to keep 1.0.2 devel around as that could make it to look
like the 1.0.2 is still fully "supported" in Fedora and there would be
no incentive to switch to 1.1.0. Also to get any new features from
upstream OpenSSL we have to move to newer versions as they are released
as the old versions get only bug fixes.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
Hello together,
is there an easy solution, maybe by regex, to strip a suffix, e.g.
'.orig', from the version-string found by Anitya / release-monitoring?
Cheers,
Björn
Hi,
nologin is listed in /etc/shells since 2002 [1].
This is in conflict with:
man 5 shells
DESCRIPTION
/etc/shells is a text file which contains the full pathnames of
valid
login shells.
man 8 nologin
DESCRIPTION
nologin displays a message that an account is not available and
exits
non-zero. It is intended as a replacement shell field to deny
login
access to an account.
NOTES
nologin is a per-account way to disable login (usually used for
system
accounts like http or ftp).
man 1 su
OPTIONS
-s, --shell=shell
Run the specified shell instead of the default.
[snip]
If the target user has a restricted shell (i.e. not listed
in
/etc/shells), the --shell option and the SHELL environment
vari‐
ables are ignored unless the calling user is root.
Actual behavior and man pages are consistent for su and nologin and their
behavior is affected indirectly by /etc/shells. The inconsistency lies in
/etc/shells containing nologin and man 5 shells semantically telling the
opposite.
Let's fix it.
The stated reason for including nologin in shells is "so that 'chsh' and
other tools will allow its use without manual edit of /etc/passwd" [1].
This is argument is inaccurate. Tests on RHEL 6.0 and fc24 showed that the
man page for chsh is correct - when /sbin/nologin is not in /etc/shells,
root can successfully run chsh -s /sbin/nologin username. It prints a
warning but it does change the default shell to /sbin/nologin. man 1 chsh:
VALID SHELLS
chsh will accept the full pathname of any executable file on the
sys‐
tem. However, it will issue a warning if the shell is not listed
in
the /etc/shells file. On the other hand, it can also be
configured
such that it will only accept shells listed in this file, unless
you
are root.
Removing /sbin/nologin from /etc/shells would prohibit a regular user to
set /sbin/nologin as the default shell for themselves - an action that
makes little sense.
/sbin/nologin being in /etc/shells poses security and logical problems:
- su -s /bin/bash - nologinuser (if "nologinuser" has /sbin/nologin as the
default shell) succeeds with /bin/bash if auth is successful [2], even
though man 1 su, man 8 nologin, and man 5 shells suggest that such a user
is a restricted user and logging in with an alternate specified shell
should be forbidden.
- Red Hat Enterprise Linux 7 Security Guide advises [3] that /sbin/nologin
should be used to prevent direct login to an account - the root account in
this example. Presumably, this should be prevented in the case where the
attacker has valid login credentials for the account. In that very case,
however, the attacker can use an ordinary account to run su -s /bin/bash -
root because the protection for this very attack present in su is rendered
useless by /sbin/nologin being listed in /etc/shells.
- selinux has a workaround for /sbin/nologin -
https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00893.html
- gdm has a workaround for /sbin/nologin -
https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00894.html
- Debian doesn't list nologin in /etc/shells. An opinion from a Debian
developer [4]: "The point of having a shell that's not in /etc/shells isn't
that you can't use it to log in, but that it's not a normal shell and that
users with that shell set can't change it to something else. Adding nologin
to /etc/shells would be very likely to open security vulnerabilities, and I
will not do it."
It seems as though /sbin/nologin is listed in /etc/shells as a workaround
to some issues without even documenting it in the man pages. These issues
are not important enough for those distributions and OSes that don't list
/sbin/nologin in /etc/shells. Maybe fedora should be on the same boat.
The rabbit hole of the past bugs and discussions about this starts here [5].
This is a bug that either lies solely in the setup package (which lists
/sbin/nologin in the /etc/shells file) or it is an inter-package bug where
multiple packages that are correct on their own exhibit an incorrect
behavior together. In any case, it is clear *something* is wrong here.
What can we do to fix this issue or to at least to make man pages
consistent with the actual behavior? Are there serious reasons to continue
listing /sbin/nologin in /etc/shells?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=53963
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1378893#c0
[3]
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/ht…
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=419132#32
[5] https://bugzilla.redhat.com/show_bug.cgi?id=1378893#c1
Thanks,
--
Jakub Svoboda / Red Hat Product Security
The versions of config.sub and config.guess in redhat-rpm-config are
3+ years old. I'd like to update these to the very latest versions,
primarily because the upstream versions support riscv64.
Is there a reason not to do that? I don't want to break something
unexpectedly.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW