10.2-BETA1: pw(8) does not support "pw useradd name -u 0"
Hi,
In our system build scripts we have this command:
/usr/sbin/pw -V $d useradd toor -u 0 -g 0 -d /root -s /bin/sh -c "Bourne-again
Superuser" -g wheel -o
After 10.2-BETA1, the toor account is being added with UID 1001 instead of UID
0. This looks like a problem with line 754 in pw_user.c, which has this test:
/*
* Check the given uid, if any
*/
if (id > 0) {
uid = (uid_t) id;
if ((pwd = GETPWUID(uid)) != NULL && conf.checkduplicate)
errx(EX_DATAERR, "uid `%u' has already been allocated",
pwd->pw_uid);
} else {
struct bitmap bm;
The (id > 0) test should probably be (id >= 0) to allow “-u 0” to be passed on
the command line.
This change is from r285092 by bapt@. Was this change in behaviour intentional?
Regards,
Jan Mikkelsen
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: r284665 causes MSI problems -> ahcich2: Timeout in slot 11 port 0
Bezüglich Harald Schmalzbauer's Nachricht vom 12.07.2015 11:59 (localtime): … >>> I can't find suspicious code in r282213 which could cause this strange >>> regression, but I verified carefully that problem arises with r284665. >>> Actually, r282901 >>> (https://svnweb.freebsd.org/base?view=revision&sortby=date&revision=282901) >>> is the real trigger, verified by putting >>> nooptions RACCT >>> nooptions RACCT_DEFAULT_TO_DISABLED >>> nooptions RCTL >>> into my kernel config -> problem vanishes! >>> >>> Setting "kern.racct.enable=1" doesn't make any difference, as soon as >>> 'kern.features.racct' exists, there's the ahci(4)/ahcich2 timeout and >>> machine doesn't finish booting. >>> >>> Unfortunately, I don't have any idea how to track this down to the >>> actual culprit, but I hope the RACCT hackers do have ;-) >>> >>> Shall I open a bugzilla ticket? >> That's... curious. I don't see how those two things could be related. >> What's the FreeBSD version? How reproducible it is? Have you tried >> compiling with and without those three lines a couple of times? > Yes, I tried several times, and falsified that with r284665 the timeouts > reproducably show up (which blocks the booting process, a major issue in > my case). > I also verified that several different revisions <284665 don't lead to > that problem, and also that the changes in ahci code paths for the last > year are not involved. > I also can't see any relation, wich doesn't mean much since I don't have > the kernel skills, but I'm sure the symptoms start with "options RACCT" While still true that I _always_ had troubles with ahcich-timeouts and "options RACCT". I now saw the same problem with kernel compiled without RACCT option :-( In this case, it's random and I had luck several times in a row, but later on, several times in a row not, when the ahcich-timeouts prevented the box from booting. So "options RACCT" does have an influence – like mentioned, I could never boot the machine with kernel >= r284665 and "options RACCT", but most times with the same kernel without "options RACCT" – but removing "options RACCT" from the kernel config is _not_ a true solution. It just improves things in the way that it's possible to boot at all – most times – but sometimes also leads to ahcich-timeouts. At least with kernel >= r284665. I couldn't re-checked with older revisions. Next chance for tests is the weekende after the next :-( Do you have an idea which race "options RACCT" could influence? Verbose booting showed in all cases (with or without timeouts) the same IRQ mapping as far as I could see. Is it likely to be a ACPI-Routing problem? Once the machine booted, I couldn't see any ahcich-timeout yet in production. Thanks, -Harry signature.asc Description: OpenPGP digital signature
Re: 10.2-BETA1: pw(8) does not support "pw useradd name -u 0"
On Mon, Jul 13, 2015 at 04:57:32PM +1000, Jan Mikkelsen wrote:
> Hi,
>
> In our system build scripts we have this command:
>
> /usr/sbin/pw -V $d useradd toor -u 0 -g 0 -d /root -s /bin/sh -c
> "Bourne-again Superuser" -g wheel -o
>
> After 10.2-BETA1, the toor account is being added with UID 1001 instead of
> UID 0. This looks like a problem with line 754 in pw_user.c, which has this
> test:
>
> /*
> * Check the given uid, if any
> */
> if (id > 0) {
> uid = (uid_t) id;
>
> if ((pwd = GETPWUID(uid)) != NULL && conf.checkduplicate)
> errx(EX_DATAERR, "uid `%u' has already been
> allocated", pwd->pw_uid);
> } else {
> struct bitmap bm;
>
>
> The (id > 0) test should probably be (id >= 0) to allow “-u 0” to be passed
> on the command line.
>
> This change is from r285092 by bapt@. Was this change in behaviour
> intentional?
Nope, I'll fix asap
Thanks for reporting
Best regards,
Bapt
pgpDnNIUX4Hk0.pgp
Description: PGP signature
Re: 10.2-BETA1: pw(8) does not support "pw useradd name -u 0"
On Mon, Jul 13, 2015 at 10:36:28AM +0200, Baptiste Daroussin wrote:
> On Mon, Jul 13, 2015 at 04:57:32PM +1000, Jan Mikkelsen wrote:
> > Hi,
> >
> > In our system build scripts we have this command:
> >
> > /usr/sbin/pw -V $d useradd toor -u 0 -g 0 -d /root -s /bin/sh -c
> > "Bourne-again Superuser" -g wheel -o
> >
> > After 10.2-BETA1, the toor account is being added with UID 1001 instead of
> > UID 0. This looks like a problem with line 754 in pw_user.c, which has this
> > test:
> >
> > /*
> > * Check the given uid, if any
> > */
> > if (id > 0) {
> > uid = (uid_t) id;
> >
> > if ((pwd = GETPWUID(uid)) != NULL && conf.checkduplicate)
> > errx(EX_DATAERR, "uid `%u' has already been
> > allocated", pwd->pw_uid);
> > } else {
> > struct bitmap bm;
> >
> >
> > The (id > 0) test should probably be (id >= 0) to allow “-u 0” to be passed
> > on the command line.
> >
> > This change is from r285092 by bapt@. Was this change in behaviour
> > intentional?
>
> Nope, I'll fix asap
>
> Thanks for reporting
>
> Best regards,
> Bapt
Fixed in head, will be merged soon in stable, I also added a regression test
about this.
Please note that you do add -g 0 and -g wheel in your command line, this is
buggy, only one should be specified.
Best regards,
bapt
pgpXGvYnqU7zZ.pgp
Description: PGP signature
WITHOUT_OPENSSL and make delete-old
Hi, I use the ports version of OpenSSL for everything and don't require the base version. As a result I thought I would remove it by adding WITHOUT_OPENSSL into /etc/src.conf and running make delete-old in /usr/src. However this seems to only want to delete things related to kerberos and gssapi, which is understandable as they depend on OpenSSL. However it doesn't seem to touch any OpenSSL files at all. Is this a bug or have I missed something? -- Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 10.1 Memory Exhaustion
.. and in one instance, you had 57gig of RAM allocated just to ZFS 65536 size buffers. -adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 10.1 Memory Exhaustion
hi, With that much storage and that many snapshots, I do think you need more than 96GB of RAM in the box. I'm hoping someone doing active ZFS work can comment.. I don't think the ZFS code is completely "memory usage" safe. The "old" Sun suggestions when I started using ZFS was "if your server panics due to out of memory with ZFS, buy more memory." That said, there doesn't look like there's a leak anywhere - those dumps show you're using at least 32gig on each just in zfs data buffers. Try tuning the ARC down a little? -adrian On 13 July 2015 at 04:48, Christopher Forgeron wrote: > > > TL;DR Summary: I can run FreeBSD out of memory quite consistently, and it’s > not a TOS/mbuf exhaustion issue. It’s quite possible that ZFS is the > culprit, but shouldn’t the pager be able to handle aggressive memory > requests in a low memory situation gracefully, without needing custom tuning > of ZFS / VM? > > > Hello, > > I’ve been dealing with some instability in my 10.1-RELEASE and > STABLEr282701M machines for the last few months. > > These machines are NFS/iSCSI storage machines, running on Dell M610x or > similar hardware, 96 Gig Memory, 10Gig Network Cards, dual Xeon Processors – > Fairly beefy stuff. > > Initially I thought it was more issues with TOS / jumbo mbufs, as I had this > problem last year. I had thought that this was properly resolved, but > setting my MTU to 1500, and turning off TOS did give me a bit more > stability. Currently all my machines are set this way. > > Crashes were usually represented by loss of network connectivity, and the > ctld daemon scrolling messages across the screen at full speed about lost > connections. > > All of this did seem like more network stack problems, but with each crash > I’d be able to learn a bit more. > > Usually there was nothing of any use in the logfile, but every now and then > I’d get this: > > Jun 3 13:02:04 san0 kernel: WARNING: 172.16.0.97 > (iqn.1998-01.com.vmware:esx5a-3387a188): failed to allocate memory > Jun 3 13:02:04 san0 kernel: WARNING: icl_pdu_new: failed to allocate 80 > bytes > Jun 3 13:02:04 san0 kernel: WARNING: 172.16.0.97 > (iqn.1998-01.com.vmware:esx5a-3387a188): failed to allocate memory > Jun 3 13:02:04 san0 kernel: WARNING: icl_pdu_new: failed to allocate 80 > bytes > Jun 3 13:02:04 san0 kernel: WARNING: 172.16.0.97 > (iqn.1998-01.com.vmware:esx5a-3387a188): failed to allocate memory > - > Jun 4 03:03:09 san0 kernel: WARNING: icl_pdu_new: failed to allocate 80 > bytes > Jun 4 03:03:09 san0 kernel: WARNING: icl_pdu_new: failed to allocate 80 > bytes > Jun 4 03:03:09 san0 kernel: WARNING: 172.16.0.97 > (iqn.1998-01.com.vmware:esx5a-3387a188): failed to allocate memory > Jun 4 03:03:09 san0 kernel: WARNING: 172.16.0.97 > (iqn.1998-01.com.vmware:esx5a-3387a188): connection error; dropping > connection > Jun 4 03:03:09 san0 kernel: WARNING: 172.16.0.97 > (iqn.1998-01.com.vmware:esx5a-3387a188): connection error; dropping > connection > Jun 4 03:03:10 san0 kernel: WARNING: 172.16.0.97 > (iqn.1998-01.com.vmware:esx5a-3387a188): waiting for CTL to terminate tasks, > 1 remaining > Jun 4 06:04:27 san0 syslogd: kernel boot file is /boot/kernel/kernel > > So knowing that it seemed to be running out of memory, I started leaving > leaving ‘vmstat 5’ running on a console, to see what it was displaying > during the crash. > > It was always the same thing: > > 0 0 0 1520M 4408M15 0 0 025 19 0 0 21962 1667 91390 > 0 33 67 > 0 0 0 1520M 4310M 9 0 0 0 2 15 3 0 21527 1385 95165 > 0 31 69 > 0 0 0 1520M 4254M 7 0 0 014 19 0 0 17664 1739 72873 > 0 18 82 > 0 0 0 1520M 4145M 2 0 0 0 0 19 0 0 23557 1447 96941 > 0 36 64 > 0 0 0 1520M 4013M 4 0 0 014 19 0 0 4288 490 34685 0 > 72 28 > 0 0 0 1520M 3885M 2 0 0 0 0 19 0 0 11141 1038 69242 > 0 52 48 > 0 0 0 1520M 3803M10 0 0 014 19 0 0 24102 1834 91050 > 0 33 67 > 0 0 0 1520M 8192B 2 0 0 0 2 15 1 0 19037 1131 77470 > 0 45 55 > 0 0 0 1520M 8192B 0 22 0 0 2 0 6 0 146 82 578 0 > 0 100 > 0 0 0 1520M 8192B 1 0 0 0 0 0 0 0 130 40 510 0 > 0 100 > 0 0 0 1520M 8192B 0 0 0 0 0 0 0 0 143 40 501 0 > 0 100 > 0 0 0 1520M 8192B 0 0 0 0 0 0 0 0 201 62 660 0 > 0 100 > 0 0 0 1520M 8192B 0 0 0 0 0 0 0 0 101 28 404 0 > 0 100 > 0 0 0 1520M 8192B 0 0 0 0 0 0 0 0 97 27 398 0 > 0 100 > 0 0 0 1520M 8192B 0 0 0 0 0 0 0 0 93 28 377 0 > 0 100 > 0 0 0 1520M 8192B 0 0 0 0 0 0 0 0 92 27 373 0 > 0 100 > > > I’d go from a decent amount of free memory to suddenly having none. Vmstat > would stop outputting, console commands would hang, etc. The whole system > would be useless. > > Looking into this, I came acro
Re: FreeBSD 10.1 Memory Exhaustion
On 7/13/2015 12:29, Adrian Chadd wrote: > hi, > > With that much storage and that many snapshots, I do think you need > more than 96GB of RAM in the box. I'm hoping someone doing active ZFS > work can comment.. > > I don't think the ZFS code is completely "memory usage" safe. The > "old" Sun suggestions when I started using ZFS was "if your server > panics due to out of memory with ZFS, buy more memory." > > That said, there doesn't look like there's a leak anywhere - those > dumps show you're using at least 32gig on each just in zfs data > buffers. That's normal. > > Try tuning the ARC down a little? The ARC is supposed to auto-size and use all available free memory. The problem is that the VM system and ARC system both make assumptions that under certain load patterns fight with one another, and when this happens and ARC wins the system gets in trouble FAST. The pattern is that the system will start to page RSS out rather than evict ARC, ARC will fill the freed space, it pages more RSS out. you see where this winds up heading yes? UMA contributes to the problem substantially when ZFS grabs chunks of RAM of a given size and then frees them as UMA will hold that RAM in reserve in the event of a subsequent allocation. For certain work patterns this can get really ugly as you can wind up with huge amounts of RAM held by the UMA system and unavailable, yet not in actual use. The patch I posted the link to has addressed both of these issues on my systems here (and a number of other people's as well); I continue to run it here in production and have been extremely happy with it. > -adrian > > > On 13 July 2015 at 04:48, Christopher Forgeron wrote: >> >> TL;DR Summary: I can run FreeBSD out of memory quite consistently, and it’s >> not a TOS/mbuf exhaustion issue. It’s quite possible that ZFS is the >> culprit, but shouldn’t the pager be able to handle aggressive memory >> requests in a low memory situation gracefully, without needing custom tuning >> of ZFS / VM? >> >> >> Hello, >> >> I’ve been dealing with some instability in my 10.1-RELEASE and >> STABLEr282701M machines for the last few months. >> >> These machines are NFS/iSCSI storage machines, running on Dell M610x or >> similar hardware, 96 Gig Memory, 10Gig Network Cards, dual Xeon Processors – >> Fairly beefy stuff. >> >> Initially I thought it was more issues with TOS / jumbo mbufs, as I had this >> problem last year. I had thought that this was properly resolved, but >> setting my MTU to 1500, and turning off TOS did give me a bit more >> stability. Currently all my machines are set this way. >> >> Crashes were usually represented by loss of network connectivity, and the >> ctld daemon scrolling messages across the screen at full speed about lost >> connections. >> >> All of this did seem like more network stack problems, but with each crash >> I’d be able to learn a bit more. >> >> Usually there was nothing of any use in the logfile, but every now and then >> I’d get this: >> >> Jun 3 13:02:04 san0 kernel: WARNING: 172.16.0.97 >> (iqn.1998-01.com.vmware:esx5a-3387a188): failed to allocate memory >> Jun 3 13:02:04 san0 kernel: WARNING: icl_pdu_new: failed to allocate 80 >> bytes >> Jun 3 13:02:04 san0 kernel: WARNING: 172.16.0.97 >> (iqn.1998-01.com.vmware:esx5a-3387a188): failed to allocate memory >> Jun 3 13:02:04 san0 kernel: WARNING: icl_pdu_new: failed to allocate 80 >> bytes >> Jun 3 13:02:04 san0 kernel: WARNING: 172.16.0.97 >> (iqn.1998-01.com.vmware:esx5a-3387a188): failed to allocate memory >> - >> Jun 4 03:03:09 san0 kernel: WARNING: icl_pdu_new: failed to allocate 80 >> bytes >> Jun 4 03:03:09 san0 kernel: WARNING: icl_pdu_new: failed to allocate 80 >> bytes >> Jun 4 03:03:09 san0 kernel: WARNING: 172.16.0.97 >> (iqn.1998-01.com.vmware:esx5a-3387a188): failed to allocate memory >> Jun 4 03:03:09 san0 kernel: WARNING: 172.16.0.97 >> (iqn.1998-01.com.vmware:esx5a-3387a188): connection error; dropping >> connection >> Jun 4 03:03:09 san0 kernel: WARNING: 172.16.0.97 >> (iqn.1998-01.com.vmware:esx5a-3387a188): connection error; dropping >> connection >> Jun 4 03:03:10 san0 kernel: WARNING: 172.16.0.97 >> (iqn.1998-01.com.vmware:esx5a-3387a188): waiting for CTL to terminate tasks, >> 1 remaining >> Jun 4 06:04:27 san0 syslogd: kernel boot file is /boot/kernel/kernel >> >> So knowing that it seemed to be running out of memory, I started leaving >> leaving ‘vmstat 5’ running on a console, to see what it was displaying >> during the crash. >> >> It was always the same thing: >> >> 0 0 0 1520M 4408M15 0 0 025 19 0 0 21962 1667 91390 >> 0 33 67 >> 0 0 0 1520M 4310M 9 0 0 0 2 15 3 0 21527 1385 95165 >> 0 31 69 >> 0 0 0 1520M 4254M 7 0 0 014 19 0 0 17664 1739 72873 >> 0 18 82 >> 0 0 0 1520M 4145M 2 0 0 0 0 19 0 0 23557 1447 96941 >> 0 36 64 >> 0 0 0 1520M 4013M 4 0 0 014 19 0 0 4288 490 34685 0 >> 72 28
Re: WITHOUT_OPENSSL and make delete-old
On Mon, Jul 13, 2015 at 7:03 AM, Matt Smith wrote: > Hi, I use the ports version of OpenSSL for everything and don't require > the base version. As a result I thought I would remove it by adding > WITHOUT_OPENSSL into /etc/src.conf and running make delete-old in /usr/src. > However this seems to only want to delete things related to kerberos and > gssapi, which is understandable as they depend on OpenSSL. However it > doesn't seem to touch any OpenSSL files at all. Is this a bug or have I > missed something? > > > -- > Matt Yes. Several critical base system components require the base OpenSL. So, I seem to recall that while WITHOUT_OPENSSL will skip the optional SSL stuff, I am pretty sure that some of the OpenSSL always are built and are considered too critical to rely on a port being installed... like logging in, adding users, etc. -- Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: WITHOUT_OPENSSL and make delete-old
On Jul 13 11:29, Kevin Oberman wrote: On Mon, Jul 13, 2015 at 7:03 AM, Matt Smith wrote: Hi, I use the ports version of OpenSSL for everything and don't require the base version. As a result I thought I would remove it by adding WITHOUT_OPENSSL into /etc/src.conf and running make delete-old in /usr/src. However this seems to only want to delete things related to kerberos and gssapi, which is understandable as they depend on OpenSSL. However it doesn't seem to touch any OpenSSL files at all. Is this a bug or have I missed something? Yes. Several critical base system components require the base OpenSL. So, I seem to recall that while WITHOUT_OPENSSL will skip the optional SSL stuff, I am pretty sure that some of the OpenSSL always are built and are considered too critical to rely on a port being installed... like logging in, adding users, etc. See now I assumed that the only things in the base that used it were Kerberos, GSSAPI, and OpenSSH. If you read the man page for src.conf it says that setting WITHOUT_OPENSSL also sets WITHOUT_KERBEROS, WITHOUT_GSSAPI, and WITHOUT_OPENSSH. This makes me think these are the only things in the base that do actually use OpenSSL? Maybe there is actually a lot more that does then. Unfortunately being the base means I can't just use pkg to look at what's registered against the shared libs. -- Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: WITHOUT_OPENSSL and make delete-old
On Mon, Jul 13, 2015 at 3:14 PM, Matt Smith wrote: > See now I assumed that the only things in the base that used it were > Kerberos, GSSAPI, and OpenSSH. If you read the man page for src.conf it > says that setting WITHOUT_OPENSSL also sets WITHOUT_KERBEROS, > WITHOUT_GSSAPI, and WITHOUT_OPENSSH. This makes me think these are the only > things in the base that do actually use OpenSSL? OpenSSL has two components, one of which is a general crypto library. I'd imagine that a lot of stuff could make use of that part of OpenSSL. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: WITHOUT_OPENSSL and make delete-old
On Mon, Jul 13, 2015 at 12:18 PM, Brandon Allbery wrote: > On Mon, Jul 13, 2015 at 3:14 PM, Matt Smith wrote: > >> See now I assumed that the only things in the base that used it were >> Kerberos, GSSAPI, and OpenSSH. If you read the man page for src.conf it >> says that setting WITHOUT_OPENSSL also sets WITHOUT_KERBEROS, >> WITHOUT_GSSAPI, and WITHOUT_OPENSSH. This makes me think these are the only >> things in the base that do actually use OpenSSL? > > > OpenSSL has two components, one of which is a general crypto library. I'd > imagine that a lot of stuff could make use of that part of OpenSSL. > > -- > brandon s allbery kf8nh sine nomine > associates > allber...@gmail.com > ballb...@sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > Annoying! ssh has explicitly never used of OpenSSL. I just confirmed that it still does not. It does use gssapi and kerberos, so even though it makes no use of OpenSSL, it does use those two things which are not actually part of OpenSSL. If you check /usr/src/crypto/openssl, there is no gssapi or kerberos there. Both of these are in the heimdal sources. Looks to me like WITHOUT_OPENSSL is really without a few other things but NOT OpenSSL. Very weird. Can anyone explain this? Or is it a bug (and a bad one as it misleads people about an important security issue). I am aware of at least one time when base ssh was newer and better than the ports version, though that is not the norm. Now that the HPC patches are in base and PKCS11 is supported, I can see little reason to use the ports version. -- Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: WITHOUT_OPENSSL and make delete-old
On Mon, Jul 13, 2015 at 6:58 PM, Kevin Oberman wrote:
> Annoying! ssh has explicitly never used of OpenSSL. I just confirmed that
> it still does not. It does use gssapi and kerberos, so even though it makes
> no use of OpenSSL, it does use those two things which are not actually part
> of OpenSSL. If you check /usr/src/crypto/openssl, there is no gssapi or
> kerberos there. Both of these are in the heimdal sources. Looks to me like
> WITHOUT_OPENSSL
> is really without a few other things but NOT OpenSSL. Very weird.
>
Um? On most platforms OpenSSH uses OpenSSL's libcrypto. This was a FAQ
nearly everywhere when there was a bug in the SSL/TLS part of OpenSSL and
OpenSSH was updated as part of it ("no, OpenSSH is not vulnerable, but it
depends on OpenSSL's libcrypto; while that part was not buggy, it had to be
updated at the same time as the buggy TLS part").
--
brandon s allbery kf8nh sine nomine associates
allber...@gmail.com ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: WITHOUT_OPENSSL and make delete-old
On 14/07/2015 12:03 AM, Matt Smith wrote: > Hi, I use the ports version of OpenSSL for everything and don't > require the base version. As a result I thought I would remove it by > adding WITHOUT_OPENSSL into /etc/src.conf and running make delete-old > in /usr/src. However this seems to only want to delete things related > to kerberos and gssapi, which is understandable as they depend on > OpenSSL. However it doesn't seem to touch any OpenSSL files at all. > Is this a bug or have I missed something? > > Matt, I've been down that road. And for a few years, I installed openssl port over openssl base. But things have changed a lot, geli uses openssl headers, libarchive (hence tar, cpio) and libarchive need openssl; and of course kerberos, openssh). Also, if you remove gssapi then you won't be build gssd (used for kernel/NFS gssapi). The way I "get around" this issue is to build a base system that uses base openssl to build the necessary "base" components, using WITHOUT_[KERBEROS,OPENSSH]. Using this base system, I build a couple of jails, which are used to build the ports. For these jails I remove any remnants of base openssl. Then I'm able to build everything and install onto the production servers only what they need. (Pay attention to where base openssl places libcom_err.*, it sometimes slips through. I have a PR for this; and a build script removes it). What you loose? The FreeBSD version of openssl is tweaked by very knowledgeable members (both Dag-Erling Smorgrav and John-Mark Gurney et al), so you may want to examine their changes. There is/was talk about making base openssl - "private" which I believe will accomplish the same result: base openssl for the base system, and port openssl for port building. I don't have details or timeline for these changes. Why did I bother? Historically - I installed heimdal 1.0.1 while base heimdal was at 0.6.3. And for my use case: no nfs, needed additional ciphers (at the time) and a slightly different attack surface; my build system works. :) I hope I've save you some time. Regards, Dewayne. -- For the talkers: “The superior man acts before he speaks, and afterwards speaks according to his action.” For everyone else: “Life is really simple, but we insist on making it complicated.” ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: WITHOUT_OPENSSL and make delete-old
On Mon, Jul 13, 2015 at 4:13 PM, Brandon Allbery
wrote:
> On Mon, Jul 13, 2015 at 6:58 PM, Kevin Oberman
> wrote:
>
>> Annoying! ssh has explicitly never used of OpenSSL. I just confirmed
>> that it still does not. It does use gssapi and kerberos, so even though it
>> makes no use of OpenSSL, it does use those two things which are not
>> actually part of OpenSSL. If you check /usr/src/crypto/openssl, there is no
>> gssapi or kerberos there. Both of these are in the heimdal sources. Looks
>> to me like WITHOUT_OPENSSL is really without a few other things but NOT
>> OpenSSL. Very weird.
>>
>
> Um? On most platforms OpenSSH uses OpenSSL's libcrypto. This was a FAQ
> nearly everywhere when there was a bug in the SSL/TLS part of OpenSSL and
> OpenSSH was updated as part of it ("no, OpenSSH is not vulnerable, but it
> depends on OpenSSL's libcrypto; while that part was not buggy, it had to be
> updated at the same time as the buggy TLS part").
>
> --
> brandon s allbery kf8nh sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
Oh, crap. I forgot that libcrypto came from OpenSSL. As Emily Littela used
to say, "Never mind".
May both Emily and Gilda rest in peace and always be remembered.
--
Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
