CVS log for src/etc/ssh/Makefile

Up to [cvs.NetBSD.org] / src / etc / ssh

Request diff between arbitrary revisions

Keyword substitution: kv
Default branch: MAIN

Pull up following revision(s) (requested by riastradh in ticket #1800):

	etc/ssh/Makefile: revision 1.4
	usr.bin/mail/Makefile: revision 1.41
	external/ibm-public/postfix/etc/Makefile: revision 1.2
	etc/bluetooth/Makefile: revision 1.6
	crypto/external/bsd/openssh/bin/Makefile: revision 1.5
	etc/root/Makefile: revision 1.5
	etc/iscsi/Makefile: revision 1.4

/root: Install .cshrc and .profile links with the same mode.

Previously we would:

1. Install /root/.cshrc and /root/.profile with mode FILESMODE=644 as
   requested in src/etc/root/Makefile and as echoed in
   /etc/mtree/special.
2. Create hard links at /.cshrc and /.profile through CONFIGLINKS.
3. Because LINKSMODE was unset and defaults to NOBINMODE=444, change
   the mode to 444.

This scenario is confusing, and mtree objects to it, which is bad for
warning fatigue in a security-relevant mechanism.  (There are also
several other files mtree objects to out of the box -- we should fix
those too.)

With this change we install the links with the same mode as the
original files, in agreement with the mtree.  The files, .cshrc and
.profile, are intended to be editable configuration files, so 644
makes sense while 444 makes no sense and gets in the way of editors
like vi.

Discussed on tech-userlevel:
https://mail-index.netbsd.org/tech-userlevel/2022/08/29/msg013498.html

etc: Fix permissions of various editable configuration files.

This way they match the mtree and make sense and don't cause editors
to ask to override read-only files when editing them.

Exception: Not sure /etc/bluetooth/protocols makes as much sense to
edit, but the mtree says 644, so if you want to change it, make sure
to change it in both places -- Makefile and mtree.

/etc/ssh: Install ssh_known_hosts with mode 644.
Makes it agree with the mtree and more convenient for admin to edit.

Pull up following revision(s) (requested by riastradh in ticket #1604):

	etc/ssh/Makefile: revision 1.4
	usr.bin/mail/Makefile: revision 1.41
	external/ibm-public/postfix/etc/Makefile: revision 1.2
	etc/bluetooth/Makefile: revision 1.6
	crypto/external/bsd/openssh/bin/Makefile: revision 1.5
	etc/root/Makefile: revision 1.5
	etc/iscsi/Makefile: revision 1.4

/root: Install .cshrc and .profile links with the same mode.

Previously we would:

1. Install /root/.cshrc and /root/.profile with mode FILESMODE=644 as
   requested in src/etc/root/Makefile and as echoed in
   /etc/mtree/special.
2. Create hard links at /.cshrc and /.profile through CONFIGLINKS.
3. Because LINKSMODE was unset and defaults to NOBINMODE=444, change
   the mode to 444.

This scenario is confusing, and mtree objects to it, which is bad for
warning fatigue in a security-relevant mechanism.  (There are also
several other files mtree objects to out of the box -- we should fix
those too.)

With this change we install the links with the same mode as the
original files, in agreement with the mtree.  The files, .cshrc and
.profile, are intended to be editable configuration files, so 644
makes sense while 444 makes no sense and gets in the way of editors
like vi.

Discussed on tech-userlevel:
https://mail-index.netbsd.org/tech-userlevel/2022/08/29/msg013498.html

etc: Fix permissions of various editable configuration files.

This way they match the mtree and make sense and don't cause editors
to ask to override read-only files when editing them.

Exception: Not sure /etc/bluetooth/protocols makes as much sense to
edit, but the mtree says 644, so if you want to change it, make sure
to change it in both places -- Makefile and mtree.

/etc/ssh: Install ssh_known_hosts with mode 644.
Makes it agree with the mtree and more convenient for admin to edit.

/etc/ssh: Install ssh_known_hosts with mode 644.

Makes it agree with the mtree and more convenient for admin to edit.

XXX pullup-8
XXX pullup-9

Remove MKCRYPTO option.

Originally, MKCRYPTO was introduced because the United States
classified cryptography as a munition and restricted its export.  The
export controls were substantially relaxed fifteen years ago, and are
essentially irrelevant for software with published source code.

In the intervening time, nobody bothered to remove the option after
its motivation -- the US export restriction -- was eliminated.  I'm
not aware of any other operating system that has a similar option; I
expect it is mainly out of apathy for churn that we still have it.
Today, cryptography is an essential part of modern computing -- you
can't use the internet responsibly without cryptography.

The position of the TNF board of directors is that TNF makes no
representation that MKCRYPTO=no satisfies any country's cryptography
regulations.

My personal position is that the availability of cryptography is a
basic human right; that any local laws restricting it to a privileged
few are fundamentally immoral; and that it is wrong for developers to
spend effort crippling cryptography to work around such laws.

As proposed on tech-crypto, tech-security, and tech-userlevel to no
objections:

https://mail-index.netbsd.org/tech-crypto/2017/05/06/msg000719.html
https://mail-index.netbsd.org/tech-security/2017/05/06/msg000928.html
https://mail-index.netbsd.org/tech-userlevel/2017/05/06/msg010547.html

P.S.  Reviewing all the uses of MKCRYPTO in src revealed a lot of
*bad* crypto that was conditional on it, e.g. DES in telnet...  That
should probably be removed too, but on the grounds that it is bad,
not on the grounds that it is (nominally) crypto.

don't install crypto files with MKCRYPTO=no.  with these changes, a
MKCRYPTO=no build completes.

Consistently use CONFIGFILES & CONFIGLINKS (which enable the 'configinstall'
target) instead of using home-grown 'distribution' targets or using
FILES with the 'install' target.
Add some etc/ subdir Makefiles where appropriate.

XXX: some of etc/Makefile install-etc-files could be converted to CONFIGFILES.