P5 bork
I am not a sophsicated user.. Im running FreeBSD 12 and Unbound at home doing DoT TLS1.3 Thats all I do on the machine. Its a very clean boring typical install. X86. FreeBSD-update fetch freebsd-update install reboot BORKED. Just loops duing boot. Backed up to kernal.old - works perfect.. If anyone cares I could go grab logs and things, but, I would assume this is already known and I will just wait for P6, hehehe.. Sorry im not deeper on the subject. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD flood of 8 breakage announcements in 3 mins.
On Wed, May 15, 2019 at 11:15 PM Bill Sorenson wrote: > > I’m not sure what you meant about Linux distros not categorizing fixes, > though — with some notable exceptions, most of the big ones certainly tag > security fixes >separately, which is what allows `unattended-upgrades` on > Debian/Ubuntu based systems (and `yum-cron` on RHEL) to work so nicely > automatically as scheduled on > *only* security errata, while leaving all > other types of updates alone for admin intervention. > > My comment about Linux was not in regards to any particular distro, they > all > have interesting policies of varying effectiveness when it comes to release > engineering, but specifically about the Linux kernel team (Torvalds Et al,) > which last I checked had a policy of specifically not handling security > issues > any different from any generic bug. Distros may do their own kernel release > engineering and handling that themselves which is fine. Understood, yep, that historical stance in the kernel itself has really sucked and does no one any favors with ‘everything is just a bug.’ Thankfully the kernel self-protection project has made some significant strides in that area, even if the overall security attitude of maintainers has been slower to positive change than would be ideal. — Matt ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD flood of 8 breakage announcements in 3 mins.
> I’m not sure what you meant about Linux distros not categorizing fixes, > though — with some notable exceptions, most of the big ones certainly tag > security fixes >separately, which is what allows `unattended-upgrades` on > Debian/Ubuntu based systems (and `yum-cron` on RHEL) to work so nicely > automatically as scheduled on > *only* security errata, while leaving all > other types of updates alone for admin intervention. My comment about Linux was not in regards to any particular distro, they all have interesting policies of varying effectiveness when it comes to release engineering, but specifically about the Linux kernel team (Torvalds Et al,) which last I checked had a policy of specifically not handling security issues any different from any generic bug. Distros may do their own kernel release engineering and handling that themselves which is fine. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD flood of 8 breakage announcements in 3 mins.
On Wed, May 15, 2019 at 9:14 PM Miroslav Lachman <000.f...@quip.cz> wrote: > > Mel Pilgrim wrote on 2019/05/16 02:30: > > [...] > > > By batching updates, FreeBSD is making administrative decisions for > > other people's systems. Some folks don't need to worry about scheduling > > downtime and will benefit from faster update availability. Folks who > > need to worry about scheduling downtime are already going to batch > > updates and should be allowed to make those decisions for themselves. > > Batched SAs help in neither case. > > > > Example: the ntpd CVE is more than two months old, and was rapidly fixed > > in ports. I was able to switch my systems to the ports ntpd during a > > scheduled downtime window in March instead of doing it this weekend. So > > not only did I benefit from the faster update availability, I was able > > to make my own decision about my own systems and significantly reduce my > > exposure. > > > > Don't be Microsoft. Don't sit on security updates. > > +1 > > Delaying / hiding security updates cannot be good. The vulnerability > already exists. Delayed updates do favor to "bad persons", not > sysadmins. Even information about found vulnerability is more valuable > for sysadmins than silence. Some vulnerabilities can be mitigated by > configuration changes or some service replacement (eg. ntpd). But if I > don't know that there is some vulnerability I cannot do anything. > > It would also be good if base system vulnerabilities are first published > in FreeBSD vuxml. Then it can be reported to sysadmins by package > security/base-audit. +1. Reporting base + ports vulnerabilities in a common way would be great. I assume that this is already part of the pkgbase project being worked on by brd and others. > > None of these recent Sec. Advisories are listed in Vuxml yet! It's bad > example of not dog fooding there. > > I am not saying that FreeBSD SO do bad work. I really appreciate it. But > there is still something to improve. > > Kind regards > Miroslav Lachman ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD flood of 8 breakage announcements in 3 mins.
Mel Pilgrim wrote on 2019/05/16 02:30: [...] By batching updates, FreeBSD is making administrative decisions for other people's systems. Some folks don't need to worry about scheduling downtime and will benefit from faster update availability. Folks who need to worry about scheduling downtime are already going to batch updates and should be allowed to make those decisions for themselves. Batched SAs help in neither case. Example: the ntpd CVE is more than two months old, and was rapidly fixed in ports. I was able to switch my systems to the ports ntpd during a scheduled downtime window in March instead of doing it this weekend. So not only did I benefit from the faster update availability, I was able to make my own decision about my own systems and significantly reduce my exposure. Don't be Microsoft. Don't sit on security updates. +1 Delaying / hiding security updates cannot be good. The vulnerability already exists. Delayed updates do favor to "bad persons", not sysadmins. Even information about found vulnerability is more valuable for sysadmins than silence. Some vulnerabilities can be mitigated by configuration changes or some service replacement (eg. ntpd). But if I don't know that there is some vulnerability I cannot do anything. It would also be good if base system vulnerabilities are first published in FreeBSD vuxml. Then it can be reported to sysadmins by package security/base-audit. None of these recent Sec. Advisories are listed in Vuxml yet! It's bad example of not dog fooding there. I am not saying that FreeBSD SO do bad work. I really appreciate it. But there is still something to improve. Kind regards Miroslav Lachman ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
FreeBSD-SA-19:03 source code patch
After applying wpa-11.patch (and the rest of the recent patches) to my 11.2 machine I'm having build problems. Looks like a binder directory and associated files did not get created. Pilot error? # uname -a FreeBSD freebsd.example.com 11.2-RELEASE FreeBSD 11.2-RELEASE #0: Thu Jan 3 19:29:29 CST 2019 r...@freebsd.example.com:/usr/obj/usr/src/sys/GENERIC amd64 --- notify.o --- cc -target x86_64-unknown-freebsd11.2 --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin -O2 -pipe -I/usr/src/usr.sbin/wpa/wpa_supplicant -I/usr/src/contrib/wpa//hostapd -I/usr/src/contrib/wpa//src -I/usr/src/contrib/wpa//src/common -I/usr/src/contrib/wpa//src/crypto -I/usr/src/contrib/wpa//src/drivers -I/usr/src/contrib/wpa//src/l2_packet -I/usr/src/contrib/wpa//src/utils -I/usr/src/contrib/wpa//src/wps -DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX -DNEED_AP_MLME -DTLS_DEFAULT_CIPHERS=\"DEFAULT:!EXP:!LOW\" -DCONFIG_BACKEND_FILE -DCONFIG_DEBUG_SYSLOG -DCONFIG_DRIVER_BSD -DCONFIG_DRIVER_NDIS -DCONFIG_DRIVER_WIRED -DCONFIG_GAS -DCONFIG_HS20 -DCONFIG_IEEE80211R -DCONFIG_INTERWORKING -DCONFIG_PEERKEY -DCONFIG_PRIVSEP -DCONFIG_SMARTCARD -DCONFIG_TERMINATE_ONLASTIF -DCONFIG_TLS=openssl -DCONFIG_WPS -DCONFIG_WPS2 -DCONFIG_WPS_UPNP -DPKCS12_FUNCS -DEAP_GTC -DEAP_LEAP -DEAP_MD5 -DEAP_MSCHAPv2 -DEAP_OTP -DEAP_PEAP -DEAP_PSK -DEAP_TLS -DEAP_TTLS -DIEEE8021X_EAPOL -DCONFIG_SHA256 -DEAP_TLS_OPENSSL -I/usr/src/usr.sbin/wpa/wpa_supplicant -I/usr/src/contrib/wpa//hostapd -I/usr/src/contrib/wpa//src -I/usr/src/contrib/wpa//src/common -I/usr/src/contrib/wpa//src/crypto -I/usr/src/contrib/wpa//src/drivers -I/usr/src/contrib/wpa//src/l2_packet -I/usr/src/contrib/wpa//src/utils -I/usr/src/contrib/wpa//src/wps -DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX -DNEED_AP_MLME -DTLS_DEFAULT_CIPHERS=\"DEFAULT:!EXP:!LOW\" -g -MD -MF.depend.notify.o -MTnotify.o -std=gnu99 -fstack-protector-strong-Qunused-arguments -c /usr/src/contrib/wpa//wpa_supplicant/notify.c -o notify.o /usr/src/contrib/wpa//wpa_supplicant/notify.c:16:10: fatal error: 'binder/binder.h' file not found #include "binder/binder.h" ^ 1 error generated. *** [notify.o] Error code 1 make[5]: stopped in /usr/src/usr.sbin/wpa/wpa_supplicant 1 error ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD flood of 8 breakage announcements in 3 mins.
On Wed, May 15, 2019 at 10:28 PM Bill Sorenson wrote: > > Admins attentive to security issues will already be tracking CVEs for > > the software they use and mitigating or solving the vulnerability by all > > means available. > > > > By batching updates, FreeBSD is making administrative decisions for > > other people's systems. Some folks don't need to worry about scheduling > > downtime and will benefit from faster update availability. Folks who > > need to worry about scheduling downtime are already going to batch > > updates and should be allowed to make those decisions for themselves. > > Batched SAs help in neither case. > > > > Example: the ntpd CVE is more than two months old, and was rapidly fixed > > in ports. I was able to switch my systems to the ports ntpd during a > > scheduled downtime window in March instead of doing it this weekend. So > > not only did I benefit from the faster update availability, I was able > > to make my own decision about my own systems and significantly reduce my > > exposure. > > > > Don't be Microsoft. Don't sit on security updates. > > I'm inclined to agree with this sentiment. I can sort of understand > holding a SA > for a week while waiting for another SA's embargo to end but beyond that I > think > the patches for Security Advisories should be made available as soon as > practical. SysAdmins need to be smart enough to plan updating strategies, > whether they can get away with patching quarterly, monthly, weekly, > immediately, > etc. It depends on the systems and the circumstances. I appreciate the SO's > work, but in my opinion if a patch to a CVE makes it to STABLE it should > be in > the patch branch within a week or so unless issues are discovered (and > depending > on the severity of the issue maybe it should be pushed anyway with > caveats.) > > FreeBSD already makes a distinction between SAs and Errata unlike some > other > projects, I think that should factor into how they are delivered. > Security Advisories should be made available quickly regardless of whether > they > are known the be exploited in the wild or we might as well just go the > Linux > route and call everything a 'bug fix' and not bother categorizing things > at all. I’m certainly not advocating holding on to SAs for an extended period of time, either: if something like the ntpd fix takes a long time to roll out on a consistent basis, maybe that’s rationale for the separate discussion of further shrinking the base system (?), since what’s ‘best’ for the majority of users in that scenario is probably getting that patched via packages/ports in days, not weeks (or months). However, I otherwise don’t find anything objectionable to releasing several ENs or SAs at once, assuming they were close in time anyway. E.g., I think it’s perfectly sane to publish 4-5 advisories/notices at once on a Thursday rather than one on Monday, one on Tuesday, two on Wednesday, etc., especially since we don’t yet have pkg base, and it fits the model of RELEASE-pX to RELEASE-pY bundling those up. I’m not sure what you meant about Linux distros not categorizing fixes, though — with some notable exceptions, most of the big ones certainly tag security fixes separately, which is what allows `unattended-upgrades` on Debian/Ubuntu based systems (and `yum-cron` on RHEL) to work so nicely automatically as scheduled on *only* security errata, while leaving all other types of updates alone for admin intervention. — Matt ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD flood of 8 breakage announcements in 3 mins.
> Admins attentive to security issues will already be tracking CVEs for > the software they use and mitigating or solving the vulnerability by all > means available. > > By batching updates, FreeBSD is making administrative decisions for > other people's systems. Some folks don't need to worry about scheduling > downtime and will benefit from faster update availability. Folks who > need to worry about scheduling downtime are already going to batch > updates and should be allowed to make those decisions for themselves. > Batched SAs help in neither case. > > Example: the ntpd CVE is more than two months old, and was rapidly fixed > in ports. I was able to switch my systems to the ports ntpd during a > scheduled downtime window in March instead of doing it this weekend. So > not only did I benefit from the faster update availability, I was able > to make my own decision about my own systems and significantly reduce my > exposure. > > Don't be Microsoft. Don't sit on security updates. I'm inclined to agree with this sentiment. I can sort of understand holding a SA for a week while waiting for another SA's embargo to end but beyond that I think the patches for Security Advisories should be made available as soon as practical. SysAdmins need to be smart enough to plan updating strategies, whether they can get away with patching quarterly, monthly, weekly, immediately, etc. It depends on the systems and the circumstances. I appreciate the SO's work, but in my opinion if a patch to a CVE makes it to STABLE it should be in the patch branch within a week or so unless issues are discovered (and depending on the severity of the issue maybe it should be pushed anyway with caveats.) FreeBSD already makes a distinction between SAs and Errata unlike some other projects, I think that should factor into how they are delivered. Security Advisories should be made available quickly regardless of whether they are known the be exploited in the wild or we might as well just go the Linux route and call everything a 'bug fix' and not bother categorizing things at all. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD flood of 8 breakage announcements in 3 mins.
On 2019-05-15 7:25, Julian H. Stacey wrote: Hi core@, cc hackers@ & stable@ PR headline : "FreeBSD flood of 8 breakage announcements in 3 mins." https://lists.freebsd.org/pipermail/freebsd-announce/2019-May/date.html Volunteers who contribute actual fixes are very much appreciated; But those styled as 'management' who delay announcements to batch floods damage us. As they've previously refused to stop, it's time to sack them. Just send each announcement out when ready, no delays to batch them. No sys admins can deal with 8 in 3 mins: Especially on multiple systems & releases. Recipients start mitigating, then more flood in, & need review which are most urgent to interrupt to; While also avoiding sudden upgrades to many servers & releases, to minimise disturbing server users, bosses & customers. Admins attentive to security issues will already be tracking CVEs for the software they use and mitigating or solving the vulnerability by all means available. By batching updates, FreeBSD is making administrative decisions for other people's systems. Some folks don't need to worry about scheduling downtime and will benefit from faster update availability. Folks who need to worry about scheduling downtime are already going to batch updates and should be allowed to make those decisions for themselves. Batched SAs help in neither case. Example: the ntpd CVE is more than two months old, and was rapidly fixed in ports. I was able to switch my systems to the ports ntpd during a scheduled downtime window in March instead of doing it this weekend. So not only did I benefit from the faster update availability, I was able to make my own decision about my own systems and significantly reduce my exposure. Don't be Microsoft. Don't sit on security updates. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD flood of 8 breakage announcements in 3 mins.
Is disagree, having them hatched causes us less work not more, as others have said one update not many, which result in one outage of systems that need patching not many. Regards Steve On Wed, 15 May 2019 at 16:48, Julian H. Stacey wrote: > Hi, Reference: > > From: Alan Somers > > Date: Wed, 15 May 2019 08:32:26 -0600 > > Alan Somers wrote: > > On Wed, May 15, 2019 at 8:26 AM Julian H. Stacey > wrote: > > > > > > Hi core@, > > > cc hackers@ & stable@ > > > > > > PR headline : "FreeBSD flood of 8 breakage announcements in 3 mins." > > > > > > > https://lists.freebsd.org/pipermail/freebsd-announce/2019-May/date.html > > > > > > Volunteers who contribute actual fixes are very much appreciated; > > > But those styled as 'management' who delay announcements to batch > floods > > > damage us. As they've previously refused to stop, it's time to sack > them. > > > > > > Just send each announcement out when ready, no delays to batch them. > > > No sys admins can deal with 8 in 3 mins: > > > Especially on multiple systems & releases. Recipients start > > > mitigating, then more flood in, & need review which are > > > most urgent to interrupt to; While also avoiding sudden upgrades > > > to many servers & releases, to minimise disturbing server users, > > > bosses & customers. > > > > > > Cheers, > > > Julian > > > -- > > > Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich > Aachen Kent > > > http://stolenvotes.uk Brexit ref. stole votes from 700,000 Brits in > EU. > > > Lies bought; Groups fined; 1.9 M young had no vote, 1.3 M old leavers > died. > > > > I disagree, Julian. I think SAs are easier to deal with when they're > > batched. True, I can't fix the first one in less than 3 minutes. But > > then I probably wouldn't even notice it that fast. Batching them all > > together means fewer updates and reboots. > > Batching also means some of these vulnerabilities could have been > fixed earlier & less of a surge of demand on recipient admins time. > > An admin can find time to ameliorate 1 bug, not 8 suddenly together. > Avoidance is called planning ahead. Giving warning of a workload. > Like an admin plans ahead & announces an outage schedule for planned > upgrade. > > Suddenly dumping 8 on admins causes overload on admin manpower. > 8 reason for users to approach admin in parallel & say > "FreeBSD seems riddled, how long will all the sudden unplanned > outages take ? Should we just dump it ?" > Dont want negative PR & lack of management. > > Cheers, > Julian > -- > Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich Aachen > Kent > http://stolenvotes.uk Brexit ref. stole votes from 700,000 Brits in EU. > Lies bought; Groups fined; 1.9 M young had no vote, 1.3 M old leavers > died. > ___ > freebsd-hack...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 12.0-RELEASE-p4 kernel panic on i386 boot
On Wed, 15 May 2019 at 00:03, Ed Maste wrote: > > On Wed, 15 May 2019 at 15:09, wintellect Auser > wrote: > > > > Hi all, > > > > Wanted to make you aware of an issue I have encountered, sorry if this is > > the wrong list. > > This is the right place and thank you for reporting. Looking into it. It looks like a new update for 12.0 i386 will be needed and will be rolled out as soon as possible. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 12.0-RELEASE-p4 kernel panic on i386 boot
On Wed, 15 May 2019 at 15:09, wintellect Auser wrote: > > Hi all, > > Wanted to make you aware of an issue I have encountered, sorry if this is > the wrong list. This is the right place and thank you for reporting. Looking into it. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 12.0-RELEASE-p4 kernel panic on i386 boot
> Hi all, > > Wanted to make you aware of an issue I have encountered, sorry if this is > the wrong list. > > I upgraded from FreeBSD 12.0-RELEASE-p3 to p4 using: > > freebsd-fetch update > freebsd-fetch install > > and use the GENERIC kernel. Upon reboot the system kernel panics when > attempting to mount the filesystem read-write. This also happens in > single-user mode if selected at boot. > > Selecting the kernel.old from the boot menu boots the system with 12-p3 and > all works fine. I have uploaded a screenshot here: > > https://imagebin.ca/v/4hCc2Kk5YqCX > > The computer is an i386 system. I also upgraded using "freebsd-update fetch install". I also went from -p3 to -p4 on an i386. My screen shot is here: https://twitter.com/DLangille/status/1128734141569208320 Hope this helps. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
12.0-RELEASE-p4 kernel panic on boot
Hi all, Wanted to make you aware of an issue I have encountered, sorry if this is the wrong list. I upgraded from FreeBSD 12.0-RELEASE-p3 to p4 using: freebsd-fetch update freebsd-fetch install and use the GENERIC kernel. Upon reboot the system kernel panics when attempting to mount the filesystem read-write. This also happens in single-user mode if selected at boot. Selecting the kernel.old from the boot menu boots the system with 12-p3 and all works fine. I have attached a screenshot. The computer is an i386 system. Thanks wintellect ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
12.0-RELEASE-p4 kernel panic on i386 boot
Hi all, Wanted to make you aware of an issue I have encountered, sorry if this is the wrong list. I upgraded from FreeBSD 12.0-RELEASE-p3 to p4 using: freebsd-fetch update freebsd-fetch install and use the GENERIC kernel. Upon reboot the system kernel panics when attempting to mount the filesystem read-write. This also happens in single-user mode if selected at boot. Selecting the kernel.old from the boot menu boots the system with 12-p3 and all works fine. I have uploaded a screenshot here: https://imagebin.ca/v/4hCc2Kk5YqCX The computer is an i386 system. Thanks wintellect ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD flood of 8 breakage announcements in 3 mins.
On Wed, May 15, 2019 at 07:15:04PM +0200, Julian H. Stacey wrote: > You make some good points, but all depend on variant circustances. I think there's validity to both points of view, and as you say I think a lot of it depends on circumstance. For example on my personal systems, where I can patch/update/change/whatever on a whim, I agree I'd rather know sooner. But I also do this professionally, and at work it's much more difficult to get a maintenance window. In that setting, where you can't patch and reboot a box every day, batching makes sense. It allows several defects to be fixed at once and actually reduces the time you're sitting with publically known issues on your running systems, waiting for RFC approval. That said, there are perhaps some things that can be done to make the process more predictable, which I'd submit for consideration to the various groups on this thread. First, perhaps there could be some advance notice when a large batch of fixes like this is about to drop. Nothing that gives details, but just something to allow enterprise admins to plan ahead and possibly be ready when the details are released. By way of example, I'm thinking of how the Samba project handled a security release which also dropped this week. [1][2] Second, to ensure things are being fixed in a reasonable manner and not waiting excessively long for a batch to queue up, perhaps secteam@ could share vulnerability timing metrics in (for example) quarterly reports, to include such things as time from initial report to released fix, time under embargo, etc. Again, doesn't have to be bug-specific, but an average would be useful. That would set the stage for a meaningful debate based on actual data, instead of just personal preferences. [1] https://lists.samba.org/archive/samba-announce/2019/000477.html [2] https://lists.samba.org/archive/samba-announce/2019/000478.html -- Greg Veldman free...@gregv.net ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD flood of 8 breakage announcements in 3 mins.
Hi. Your friendly neighborhood Security Officer here. I published the 5 advisories and 3 errata yesterday. On Wed, May 15, 2019 at 07:15:04PM +0200, Julian H. Stacey wrote: > Thanks Will, > You make some good points, but all depend on variant circustances. > > I prefer to be informed ASAP, to make my own decisons with max info ASAP, > Not delayed. I want freebsd.org to Not Delay fix announcements into batches. All but one of the fixes was already in the STABLE branches. So if you wanted to track something that would get things as immediate as possible, I would recommend looking at the STABLE branches, you just won't get freebsd-update bits there. Just to put a line in the sand here, I will always be batching advisories when it works in my judgement. Granted, this batch was larger than I wanted it to be; I ran out of time over the past couple of months to get everything together (real life and all getting in the way). There are two reasons I will batch: 1. Our users and the industry have a preference for batched updates. 2. There is a large upfront cost for getting the freebsd-update bits built. Meaning the time to do 1 advisory vs the time to do 8 makes it worthwhile to batch. No offense, but I value my time. I only have so much to devote to FreeBSD. > As soon as exploits are in the wild, some will exploit, > not announcing until binary updates are ready gives black hats more time. Welcome to the push/pull of dealing with security. It is a risk based decision, but I have the unenviable position of trying to make the best risk based decision for the entire community. By definition, not everyone will be happy with the decision. > PS Here seems (*) an example of something in text config didnt even > need to wait for src/ let alone bin. * Not sure, I'll try it later, > got to dash off line. > > https://lists.freebsd.org/pipermail/freebsd-announce/2019-May/001878.html > ] IV. Workaround > ] Use 'restrict noquery' in the ntpd configuration to limit addresses that > ] can send mode 6 queries. I would note this is already the default config. Best regards, Gordon ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD flood of 8 breakage announcements in 3 mins.
Thanks Will, You make some good points, but all depend on variant circustances. I prefer to be informed ASAP, to make my own decisons with max info ASAP, Not delayed. I want freebsd.org to Not Delay fix announcements into batches. If other admins want to delay being told told to do upgrades until there's lots more to consider & upgrade, they can dummy the delay their receive end, just filtering announcements into their own special box they read once per period. As soon as exploits are in the wild, some will exploit, not announcing until binary updates are ready gives black hats more time. > Whatever other negative things you can say about them, I don't hear > enterprise admins begging that Microsoft/Oracle/whoever would dribble out > patches one at a time each week instead of combining them like they do; it > seems like it works just fine for everyone else. MS make lots of money from the addicted cluless, despite MS loosers frequently complain eg that PCs are locked up again in mid auto update & owner can't shut down to catch a plane or train. MS servers I avoid like the plague. PS Here seems (*) an example of something in text config didnt even need to wait for src/ let alone bin. * Not sure, I'll try it later, got to dash off line. https://lists.freebsd.org/pipermail/freebsd-announce/2019-May/001878.html ] IV. Workaround ] Use 'restrict noquery' in the ntpd configuration to limit addresses that ] can send mode 6 queries. Cheers, Julian -- Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich Aachen Kent http://stolenvotes.uk Brexit ref. stole votes from 700,000 Brits in EU. Lies bought; Groups fined; 1.9 M young had no vote, 1.3 M old leavers died. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD flood of 8 breakage announcements in 3 mins.
> On May 15, 2019, at 12:28 PM, Andrea Venturoli wrote: > > On 5/15/19 6:16 PM, Matt Garber wrote: > >> Exactly. If batching 8 (or more) individual bugs/issues together into >> one release is really causing admin/manpower overload and angst,then >> maybe it’s time in your situation to use the binary updates (which >> would only be a single `freebsd-update` and reboot, so there would >> be no ‘sudden unplanned outages’) rather than tracking src and >> remediating each individual bug at a time. > > Maybe I'm dumb, but I still don't get what "src vs binary" has to do with "8 > vs 1"... > I ran a single "svn update; make buildworld; make kernel; make installworld; > reboot", not 8... > > bye > av. Agreed. But if, say, you were tracking specific svn revisions rather than just jumping to the latest, I *guess* it might involve 8 separate builds? I certainly prefer one, batched downtime event to address across all affected systems, regardless of binary updates or src, and I imagine most other individuals/companies/organizations do, too. -- Matt ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD flood of 8 breakage announcements in 3 mins.
Kurt Jaeger wrote: > Hi! > > > > > Alternative is to for announcers to do Less work: > > > > Send each announcement when ready. > > > > The problem is not the announcement, the problem is providing > > > the freebsd-update. > > > > If announcements are send when ready, and the freebsd-update is > > > not ready, therefore, the timeframes to attack systems with unpatched > > > problems are much longer. > > > True as far as that goes for binary users, but often source patches > > are available faster, which begs the question: when to announce ? > > When there's diffs ? When diffs are commited to src/ (used to be the norm > > *) ? > > When there's some binary update ? > > Whne a whole bunch of 8 arrive in 3 minutes ? Gasp ! > > Now I understand why you bring this up. > > I guess the majority of users are using the binary update path. Hmm, a distinct possibility, that could be a problem delaying announcements. > Maybe re@ can explain how the process is for these steps ? I assumed re@ (periodicaly overworked team who presumably collapse in appreciated exhaustion after valuable work rolling releases), were [largely] different people? Cheers, Julian -- Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich Aachen Kent http://stolenvotes.uk Brexit ref. stole votes from 700,000 Brits in EU. Lies bought; Groups fined; 1.9 M young had no vote, 1.3 M old leavers died. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD flood of 8 breakage announcements in 3 mins.
On 5/15/19 6:16 PM, Matt Garber wrote: Exactly. If batching 8 (or more) individual bugs/issues together into one release is really causing admin/manpower overload and angst,then maybe it’s time in your situation to use the binary updates (which would only be a single `freebsd-update` and reboot, so there would be no ‘sudden unplanned outages’) rather than tracking src and remediating each individual bug at a time. Maybe I'm dumb, but I still don't get what "src vs binary" has to do with "8 vs 1"... I ran a single "svn update; make buildworld; make kernel; make installworld; reboot", not 8... bye av. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD flood of 8 breakage announcements in 3 mins.
> On May 15, 2019, at 12:12 PM, Will Andrews wrote: > > On Wed, May 15, 2019 at 10:45 AM Julian H. Stacey wrote: > >> Batching also means some of these vulnerabilities could have been >> fixed earlier & less of a surge of demand on recipient admins time. >> >> An admin can find time to ameliorate 1 bug, not 8 suddenly together. >> Avoidance is called planning ahead. Giving warning of a workload. >> Like an admin plans ahead & announces an outage schedule for planned >> upgrade. >> >> Suddenly dumping 8 on admins causes overload on admin manpower. >> 8 reason for users to approach admin in parallel & say >> "FreeBSD seems riddled, how long will all the sudden unplanned >> outages take ? Should we just dump it ?" >> Dont want negative PR & lack of management. >> > > What admins prefer 8 downtime events instead of 1? > > —Will. Exactly. If batching 8 (or more) individual bugs/issues together into one release is really causing admin/manpower overload and angst, then maybe it’s time in your situation to use the binary updates (which would only be a single `freebsd-update` and reboot, so there would be no ‘sudden unplanned outages’) rather than tracking src and remediating each individual bug at a time. I understand that might be mutually exclusive with other reasons why you don’t already use binary updates or prefer to track src for the base system, but there are always compromises and trade-offs to everything, and batching seems preferable to any alternatives. You’d seriously want to run reboots across a server fleet every other day for two weeks if there were 8 separate patches staggered out? That’s insanity, and is way more of a PR problem from a ‘should we just dump it’ perspective. You mention ‘announces an outage schedule for planned upgrade’, but that’s really its own form of internal batching – it shouldn’t make any difference if you’re technically pushing 1 or 8 bug/security fixes during that pre-identified period of time: all of your other internal processes like maintaining a test group for detecting regressions, using boot environments (or other storage features) to allow for rollbacks, etc. all continue to work as intended. Any potential negative PR within your company/organization seems like it would be related to how else you’re handling the upgrade process(es), not whether the fixes are batched or not. Whatever other negative things you can say about them, I don’t hear enterprise admins begging that Microsoft/Oracle/whoever would dribble out patches one at a time each week instead of combining them like they do; it seems like it works just fine for everyone else. ¯\_(ツ)_/¯ Thanks, — Matt Garber ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD flood of 8 breakage announcements in 3 mins.
On Wed, May 15, 2019 at 10:45 AM Julian H. Stacey wrote: > Batching also means some of these vulnerabilities could have been > fixed earlier & less of a surge of demand on recipient admins time. > > An admin can find time to ameliorate 1 bug, not 8 suddenly together. > Avoidance is called planning ahead. Giving warning of a workload. > Like an admin plans ahead & announces an outage schedule for planned > upgrade. > > Suddenly dumping 8 on admins causes overload on admin manpower. > 8 reason for users to approach admin in parallel & say > "FreeBSD seems riddled, how long will all the sudden unplanned > outages take ? Should we just dump it ?" > Dont want negative PR & lack of management. > What admins prefer 8 downtime events instead of 1? --Will. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD flood of 8 breakage announcements in 3 mins.
On Wed, May 15, 2019 at 05:58:38PM +0200, Kurt Jaeger wrote: > Hi! > > > > > Alternative is to for announcers to do Less work: > > > > Send each announcement when ready. > > > > The problem is not the announcement, the problem is providing > > > the freebsd-update. > > > > If announcements are send when ready, and the freebsd-update is > > > not ready, therefore, the timeframes to attack systems with unpatched > > > problems are much longer. > > > True as far as that goes for binary users, but often source patches > > are available faster, which begs the question: when to announce ? > > When there's diffs ? When diffs are commited to src/ (used to be the norm > > *) ? > > When there's some binary update ? > > Whne a whole bunch of 8 arrive in 3 minutes ? Gasp ! > > Now I understand why you bring this up. > > I guess the majority of users are using the binary update path. > > Maybe re@ can explain how the process is for these steps ? > This is an so@ thing (CCd). re@ does not have any involvement in this process. Glen signature.asc Description: PGP signature
Re: FreeBSD flood of 8 breakage announcements in 3 mins.
Hi! > > > Alternative is to for announcers to do Less work: > > > Send each announcement when ready. > > The problem is not the announcement, the problem is providing > > the freebsd-update. > > If announcements are send when ready, and the freebsd-update is > > not ready, therefore, the timeframes to attack systems with unpatched > > problems are much longer. > True as far as that goes for binary users, but often source patches > are available faster, which begs the question: when to announce ? > When there's diffs ? When diffs are commited to src/ (used to be the norm *) ? > When there's some binary update ? > Whne a whole bunch of 8 arrive in 3 minutes ? Gasp ! Now I understand why you bring this up. I guess the majority of users are using the binary update path. Maybe re@ can explain how the process is for these steps ? -- p...@freebsd.org +49 171 3101372 One year to go ! ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD flood of 8 breakage announcements in 3 mins.
Hi, Reference: > From: Kurt Jaeger > Date: Wed, 15 May 2019 17:38:36 +0200 Kurt Jaeger wrote: > Hi! > > > > > PR headline : "FreeBSD flood of 8 breakage announcements in 3 mins." > > > > > > > > https://lists.freebsd.org/pipermail/freebsd-announce/2019-May/date.html > > > > > > > > Volunteers who contribute actual fixes are very much appreciated; > > > > But those styled as 'management' who delay announcements to batch floods > > > > damage us. > > > > > > 8 announcements and one freebsd-update is easier on the > > > admin and the re-team than 8 announcements and 8 freebsd-update runs. > > > > > > That's probably why they are batched. Because all of the fixes > > > are bundled in one update. > > > > > > If the re-team-capacity is limited, what would be the alternative? > > > Alternative is to for announcers to do Less work: > > Send each announcement when ready. > > The problem is not the announcement, the problem is providing > the freebsd-update. > > If announcements are send when ready, and the freebsd-update is > not ready, therefore, the timeframes to attack systems with unpatched > problems are much longer. True as far as that goes for binary users, but often source patches are available faster, which begs the question: when to announce ? When there's diffs ? When diffs are commited to src/ (used to be the norm *) ? When there's some binary update ? Whne a whole bunch of 8 arrive in 3 minutes ? Gasp ! * I happen to use src/ never use freebsd-update. Equally bound to be some who use binary updates & not source Cheers, Julian -- Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich Aachen Kent http://stolenvotes.uk Brexit ref. stole votes from 700,000 Brits in EU. Lies bought; Groups fined; 1.9 M young had no vote, 1.3 M old leavers died. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD flood of 8 breakage announcements in 3 mins.
Hi, Reference: > From: Alan Somers > Date: Wed, 15 May 2019 08:32:26 -0600 Alan Somers wrote: > On Wed, May 15, 2019 at 8:26 AM Julian H. Stacey wrote: > > > > Hi core@, > > cc hackers@ & stable@ > > > > PR headline : "FreeBSD flood of 8 breakage announcements in 3 mins." > > > > https://lists.freebsd.org/pipermail/freebsd-announce/2019-May/date.html > > > > Volunteers who contribute actual fixes are very much appreciated; > > But those styled as 'management' who delay announcements to batch floods > > damage us. As they've previously refused to stop, it's time to sack them. > > > > Just send each announcement out when ready, no delays to batch them. > > No sys admins can deal with 8 in 3 mins: > > Especially on multiple systems & releases. Recipients start > > mitigating, then more flood in, & need review which are > > most urgent to interrupt to; While also avoiding sudden upgrades > > to many servers & releases, to minimise disturbing server users, > > bosses & customers. > > > > Cheers, > > Julian > > -- > > Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich Aachen > > Kent > > http://stolenvotes.uk Brexit ref. stole votes from 700,000 Brits in EU. > > Lies bought; Groups fined; 1.9 M young had no vote, 1.3 M old leavers died. > > I disagree, Julian. I think SAs are easier to deal with when they're > batched. True, I can't fix the first one in less than 3 minutes. But > then I probably wouldn't even notice it that fast. Batching them all > together means fewer updates and reboots. Batching also means some of these vulnerabilities could have been fixed earlier & less of a surge of demand on recipient admins time. An admin can find time to ameliorate 1 bug, not 8 suddenly together. Avoidance is called planning ahead. Giving warning of a workload. Like an admin plans ahead & announces an outage schedule for planned upgrade. Suddenly dumping 8 on admins causes overload on admin manpower. 8 reason for users to approach admin in parallel & say "FreeBSD seems riddled, how long will all the sudden unplanned outages take ? Should we just dump it ?" Dont want negative PR & lack of management. Cheers, Julian -- Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich Aachen Kent http://stolenvotes.uk Brexit ref. stole votes from 700,000 Brits in EU. Lies bought; Groups fined; 1.9 M young had no vote, 1.3 M old leavers died. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD flood of 8 breakage announcements in 3 mins.
Hi! > > > PR headline : "FreeBSD flood of 8 breakage announcements in 3 mins." > > > > > > https://lists.freebsd.org/pipermail/freebsd-announce/2019-May/date.html > > > > > > Volunteers who contribute actual fixes are very much appreciated; > > > But those styled as 'management' who delay announcements to batch floods > > > damage us. > > > > 8 announcements and one freebsd-update is easier on the > > admin and the re-team than 8 announcements and 8 freebsd-update runs. > > > > That's probably why they are batched. Because all of the fixes > > are bundled in one update. > > > > If the re-team-capacity is limited, what would be the alternative? > Alternative is to for announcers to do Less work: > Send each announcement when ready. The problem is not the announcement, the problem is providing the freebsd-update. If announcements are send when ready, and the freebsd-update is not ready, therefore, the timeframes to attack systems with unpatched problems are much longer. -- p...@freebsd.org +49 171 3101372 One year to go ! ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD flood of 8 breakage announcements in 3 mins.
Kurt Jaeger wrote: > Hi! > > > PR headline : "FreeBSD flood of 8 breakage announcements in 3 mins." > > > > https://lists.freebsd.org/pipermail/freebsd-announce/2019-May/date.html > > > > Volunteers who contribute actual fixes are very much appreciated; > > But those styled as 'management' who delay announcements to batch floods > > damage us. > > 8 announcements and one freebsd-update is easier on the > admin and the re-team than 8 announcements and 8 freebsd-update runs. > > That's probably why they are batched. Because all of the fixes > are bundled in one update. > > If the re-team-capacity is limited, what would be the alternative? Alternative is to for announcers to do Less work: Send each announcement when ready. Do not do extra work delaying, storing, batch announcing. Announcements to recipients not delayed, without flooding. > > -- > p...@opsec.eu+49 171 3101372One year to go ! > Cheers, Julian -- Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich Aachen Kent http://stolenvotes.uk Brexit ref. stole votes from 700,000 Brits in EU. Lies bought; Groups fined; 1.9 M young had no vote, 1.3 M old leavers died. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD flood of 8 breakage announcements in 3 mins.
Hi! > PR headline : "FreeBSD flood of 8 breakage announcements in 3 mins." > > https://lists.freebsd.org/pipermail/freebsd-announce/2019-May/date.html > > Volunteers who contribute actual fixes are very much appreciated; > But those styled as 'management' who delay announcements to batch floods > damage us. 8 announcements and one freebsd-update is easier on the admin and the re-team than 8 announcements and 8 freebsd-update runs. That's probably why they are batched. Because all of the fixes are bundled in one update. If the re-team-capacity is limited, what would be the alternative? -- p...@opsec.eu+49 171 3101372One year to go ! ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD flood of 8 breakage announcements in 3 mins.
On Wed, May 15, 2019 at 8:26 AM Julian H. Stacey wrote: > > Hi core@, > cc hackers@ & stable@ > > PR headline : "FreeBSD flood of 8 breakage announcements in 3 mins." > > https://lists.freebsd.org/pipermail/freebsd-announce/2019-May/date.html > > Volunteers who contribute actual fixes are very much appreciated; > But those styled as 'management' who delay announcements to batch floods > damage us. As they've previously refused to stop, it's time to sack them. > > Just send each announcement out when ready, no delays to batch them. > No sys admins can deal with 8 in 3 mins: > Especially on multiple systems & releases. Recipients start > mitigating, then more flood in, & need review which are > most urgent to interrupt to; While also avoiding sudden upgrades > to many servers & releases, to minimise disturbing server users, > bosses & customers. > > Cheers, > Julian > -- > Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich Aachen Kent > http://stolenvotes.uk Brexit ref. stole votes from 700,000 Brits in EU. > Lies bought; Groups fined; 1.9 M young had no vote, 1.3 M old leavers died. I disagree, Julian. I think SAs are easier to deal with when they're batched. True, I can't fix the first one in less than 3 minutes. But then I probably wouldn't even notice it that fast. Batching them all together means fewer updates and reboots. -Alan ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
FreeBSD flood of 8 breakage announcements in 3 mins.
Hi core@, cc hackers@ & stable@ PR headline : "FreeBSD flood of 8 breakage announcements in 3 mins." https://lists.freebsd.org/pipermail/freebsd-announce/2019-May/date.html Volunteers who contribute actual fixes are very much appreciated; But those styled as 'management' who delay announcements to batch floods damage us. As they've previously refused to stop, it's time to sack them. Just send each announcement out when ready, no delays to batch them. No sys admins can deal with 8 in 3 mins: Especially on multiple systems & releases. Recipients start mitigating, then more flood in, & need review which are most urgent to interrupt to; While also avoiding sudden upgrades to many servers & releases, to minimise disturbing server users, bosses & customers. Cheers, Julian -- Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich Aachen Kent http://stolenvotes.uk Brexit ref. stole votes from 700,000 Brits in EU. Lies bought; Groups fined; 1.9 M young had no vote, 1.3 M old leavers died. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
(#2572022) Ticket gesloten door support
-#-#- Antwoord u boven deze lijn alstublieft -#-#- Beste freebsd-stable@freebsd.org, Uw ticket is gesloten door een supportmedewerker. Indien u van mening bent dat het probleem niet volledig is opgelost, dan kunt u antwoorden op deze e-mail. Your ticket has been marked as resolved by a member of our staff. If you do not believe that this issue has been adequately resolved, you may still reply to this ticket and an operator will respond shortly. You can review the ticket by going to: https://support.marmac.nl/nl/tickets/view/2572022?token=bbc117f8dea7bbe09d749a28bcddea263cefce3b --- freebsd-stable@freebsd.org User - 15/05/2019 02:45 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 = FreeBSD-EN-19:10.scp Errata Notice The FreeBSD Project Topic: Insufficient filename validation in scp(1) client Category: contrib Module: scp Announced: 2019-05-14 Affects: All supported versions of FreeBSD. Corrected: 2019-05-07 19:48:39 UTC (stable/12, 12.0-STABLE) 2019-05-14 22:54:17 UTC (releng/12.0, 12.0-RELEASE-p10) CVE Name: CVE-2019-6111 For general information regarding FreeBSD Errata Notices and Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit https://security.FreeBSD.org/>. I. Background scp(1) is a file transfer protocol running over an SSH session. II. Problem Description The scp(1) client implementation fails to verify if the objects returned by the server match what was requested. III. Impact A malicious scp server can write arbitrary files to the client. IV. Workaround Switch to using the sftp(1) client, if possible. V. Solution Note: While stable/11 and its release branches are currently affected by this errata, due to the lack of patches, no fix is currently available for stable/11. We are currently evaluating a backport for these fixes to stable/11. Perform one of the following: 1) Upgrade your system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. 2) To update your system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install 3) To update your system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. [FreeBSD 12.0] # fetch https://security.FreeBSD.org/patches/EN-19:10/scp.patch # fetch https://security.FreeBSD.org/patches/EN-19:10/scp.patch.asc # gpg --verify scp.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile the operating system using buildworld and installworld as described in https://www.FreeBSD.org/handbook/makeworld.html>. VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - - stable/12/ r347232 releng/12.0/ r347586 - - To see which files were modified by a particular revision, run the following command, replacing NN with the revision number, on a machine with Subversion installed: # svn diff -cNN --summarize svn://svn.freebsd.org/base Or visit the following URL, replacing NN with the revision number: https://svnweb.freebsd.org/base?view=revision=NN> VII. References https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6111> The latest revision of this advisory is available at https://security.FreeBSD.org/advisories/FreeBSD-EN-19:10.scp.asc> -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAlzbTq1fFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n 5cJXGQ/+Ii19QUq6MdSeNPPOHVTtW8G/FIlsaYYlCFooIvzxYxvcqDcCyabVlX/a Lt815YY7+EbKcSbA0Gh/YFm9S05rwUg4Dnj8nIQwMVp9OEtziIdY6TVU0JhRoUpe +YVG9e5eh8wK7FFJ/jIaZbAcr2MfMYV2KPouA1HZdqsMBkAkr8xuS3HrmkeE0nxo 6QHTWaaD7qvr8foUSHS1hJsAX3+1eIsdytGUTJIGeL6g7DWsLYYiX7v2k+eZuSe1 dkt7/3J+RqpyJAv+LfGh3QnILC52fO7jOVlnOBt5H/HefX+xRdb8lwHfoBeyxIFc N4v4Ecypewci6Hv4moTeZF+FtIETHj3EfPIe04eiikiGhrpGQ4cCveK6+kk49x4m RR7TE+y7klGIfoSuxoooaJ1/UyFJ9T0eICmBUh1B5rcrnwbbhgpXVPpbbee7IFL2 HYiEuDECPN45zek+bL0M5D0wHZc823e7p1Ioxl1NNzawdts7hWwIpNmFTlfWNczQ KZ9y0bDFffK3nuUkMHORLagCM6ou/wAPunsnWXY3Xg3X61svYIvZThDIeeOi9SbF d1ve8/H/t5yHRQBpqWk51FfO4RdPmQAo6Y9w9WzhnkETsNXeTruQq7D8SnOaWgXG JUh9PAVQKcJRWPXVwDTPEsqRgaDVB0gpaPCt5IS2j2tyB8UuAd4= =2h+W -END PGP SIGNATURE- ___ freebsd-annou...@freebsd.org mailing list
(#3759419) Ticket gesloten door support
-#-#- Antwoord u boven deze lijn alstublieft -#-#- Beste freebsd-stable@freebsd.org, Uw ticket is gesloten door een supportmedewerker. Indien u van mening bent dat het probleem niet volledig is opgelost, dan kunt u antwoorden op deze e-mail. Your ticket has been marked as resolved by a member of our staff. If you do not believe that this issue has been adequately resolved, you may still reply to this ticket and an operator will respond shortly. You can review the ticket by going to: https://support.marmac.nl/nl/tickets/view/3759419?token=852ccf79da96df0d5f7bee1d93a70dc9f58f6f14 --- freebsd-stable@freebsd.org User - 15/05/2019 02:30 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 = FreeBSD-EN-19:09.xinstall Errata Notice The FreeBSD Project Topic: install(1) broken with partially matching relative paths Category: core Module: xinstall Announced: 2019-05-14 Affects: All supported versions of FreeBSD Corrected: 2019-02-16 04:48:30 UTC (stable/12, 12.0-STABLE) 2019-05-14 22:51:49 UTC (releng/12.0, 12.0-RELEASE-p4) 2019-02-16 04:49:10 UTC (stable/11, 11.3-PRERELEASE) 2019-05-14 22:51:49 UTC (releng/11.2, 11.2-RELEASE-p10) For general information regarding FreeBSD Errata Notices and Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit https://security.FreeBSD.org/>. I. Background The install(1) utility installs files and links, optionally calculating relative paths for an installed symbolic link. II. Problem Description Due to an issue in the way install(1) determines common components of the source and target paths, the relative link may be incorrectly calculated and drop a component of the link because a partial match existed on that component. III. Impact The ports tree and other software very frequently use install(1) to create relative symlinks without checking whether a partial match of the path exists that would result in such a truncation. IV. Workaround No workaround is available, but using install(1) to install non-relative links and files is unaffected. V. Solution Perform one of the following: 1) Upgrade your system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. 2) To update your system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install 3) To update your system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch https://security.FreeBSD.org/patches/EN-19:09/xinstall.patch # fetch https://security.FreeBSD.org/patches/EN-19:09/xinstall.patch.asc # gpg --verify xinstall.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile the operating system using buildworld and installworld as described in https://www.FreeBSD.org/handbook/makeworld.html>. VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - - stable/12/ r344205 releng/12.0/ r347585 stable/11/ r344206 releng/11.2/ r347585 - - To see which files were modified by a particular revision, run the following command, replacing NN with the revision number, on a machine with Subversion installed: # svn diff -cNN --summarize svn://svn.freebsd.org/base Or visit the following URL, replacing NN with the revision number: https://svnweb.freebsd.org/base?view=revision=NN> VII. References https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235330> The latest revision of this advisory is available at https://security.FreeBSD.org/advisories/FreeBSD-EN-19:09.xinstall.asc> -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAlzbTqhfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n 5cJV2RAAjFslsJRGQlL5piJPcAixaQO3gEgmaAp+q79whcsN3O8cqQpApU0BApTA cT7cNnm3/sMteHFd6wCTLsssBnDsTWYxqccOeUIiCIgpXXkP67XYpLxxjBZqq5Tn egFesjpZdu2yr+0gdRrpf54msed7ts8E0dDVoGIYeGhU7omIqlYWJGJfsZ4tg1La Mod40JgxXcHMTca7Et46LBu/j/cF5MeQhzIepRrj1awiElQY/dMesmJwD9AuYL9m cuS7yTH4eC6A/b7TdhUXBqBTbNipUCmwUuIWJ6OxpcrKPrtv/qGhUCEDdsNvMxpA i8ciQY4YD06wdmZP+9Ugp/qXMXpLlxzwHrUYPe/Xn6/NvUgMp+KyMWgfkmtPBuIl YKRTp5S4ZAs6U7RPSOMUWmQ2bWh0yZqEaQXAgzzNwIpqdghrZj73krr99pCeWc81 1MWv6K9/ZMdm8i31Iur3Mz/4hkv5WQSObU9SdjigtvFGu5ldVEJzE5f3Zu9Vr5ja
