Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-19:07.mds

2019-05-15 Thread Jan Bramkamp 

On 15.05.19 14:18, Wall, Stephen wrote:

New CPU microcode may be available in a BIOS update from your system vendor,
or by installing the devcpu-data package or sysutils/devcpu-data port.
Ensure that the BIOS update or devcpu-data package is dated after 2014-05-14.

If using the package or port the microcode update can be applied at boot time
by adding the following lines to the system's /boot/loader.conf:

cpu_microcode_load="YES"
cpu_microcode_name="/boot/firmware/intel-ucode.bin"

Is this applicable in a virtualized environment, or only on bare metal?
If not applicable in a VM, is it at least harmless?
Afaik you can't modify the microcode inside a VM, but give them time. 
I'm sure Intel optimized that security check away as well in some corner 
case yet to be discovered.

___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

2017-12-12 Thread Jan Bramkamp 


On 12.12.17 15:28, Poul-Henning Kamp wrote:

For the FreeBSD SVN tree, this could almost be as simple as posting
an email, maybe once a week, with the exact revision checked out
and the PGP signed output of:

svn co ... && find ... -print | sort | xargs cat | sha256

Such an archive would also be invaluable for reauthenticating in
case, somebody ever manages to do something evil to our repo.


Solve the problem at the correct location -- either fix svn to sign and
verify updates or dump it for something that can and use that existing
mechanism (e.g. git)


As I mentioned humoursly to you in private email, I don't think
this particular problem will reach consensus any sooner if you
also tangling it in the SVN vs GIT political issue.


How about an uncompressed tarball signed with signify? It could be 
replicated with rsync (or zsync) and getting security patches wouldn't 
require lots of network bandwidth.


I still prefer to encrypt every transfer with PFS only protocols, but 
even with transport encryption in place content authentication is still 
valuable because it allows the use of caching proxies.

___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"