Last week in BSD
Releases: SmallWall, OPNsesnse, DragonFly BSDOther news: BSDSec, DragonFly BSD, HardenedBSD, LibreSSL, NetBSD, OPNsense, SmallWall, Wallpaper, SmallWall, NetBSD, BSDnow
Check out DiscoverBSD stats - or some stats for DiscoverBSD, BSD-Links and BSDsec.
BSDSec
Releases
SmallWall 1.8.2 released and 1.8.3 bugfix release
A bug was found in syslog in the 1.8.2 build, so there
is now a 1.8.3 released to patch that build bug.
DragonFly 4.2 and 4.0.6 branched
The more eagle-eyed may have noticed a branching for DragonFly 4.2, and for DragonFly 4.0.6. The 4.2 branch is currently only a release candidate, so don’t necessarily change over yet – it’s for testing, not release.
Note
that packages for 4.2 are not yet built, so you’ll have to manually
specify a package path to install with pkg on 4.2 – for now.. That won’t
be the case for the actual release, of course. DragonFly 4.3
users will have to specify PKG_PATH manually to use 4.2 images until new
ones are built. 4.2 release candidate users will be fine. (see
comments for correction.)
The 4.0.6 release is mostly to get the recent OpenSSL update into a 4.0.x build.
I am working on image building for both.
The 4.0.6 release is mostly to get the recent OpenSSL update into a 4.0.x build.
I am working on image building for both.
DragonFly 4.0.6 image up
I’ve uploaded DragonFly 4.0.6 ISO and .img files. (Does that capitalization make sense?) They should be available at your nearest mirror, or will be shortly. I am still working on the 4.2 release candidate images.
OPNsense version 15.1.11.4 Released
Here is the full list of changes:- notable ports updates: pcre 8.37_1 [1], phalcon 2.0.2 [2], strongswan 5.3.2 [3], sqlite 3.8.10.2 [4]
- more notable ports: openvpn 2.3.7 [5], openssl 1.0.2b [6], libressl 2.1.7 [7], pkg 1.5.4 [8]
- opnsense-update: has gained the ability to do package updates as well
- core: removed unused ssh_tunnel_shell and 3gstats utilities, added sudo to the default utilities
- captiveportal/traffic shaper: better fix for localhost skip
- traffic shaper: added ICMP, IGMP, ESP, AH and GRE protocols to selectable protocols
- core: fixed a bug that prevented our API from working properly with Phalcon 2.0.1 and above
- backend: added configctl command utility launcher and improved its logging capabilities
- backend: worked around a performance degradation bug in Python 2.7 on FreeBSD
- gateways: monitoring via `apinger’ is now turned off by default for all new gateways created (opt-out flipped to opt-in for privacy reasons)
- firmware: refactored firmware code to use opnsense-update’s new capabilities
- firmware: fix parsing of packages to be upgraded in fringe cases
- firmware: fix overzealous caching of available package upgrades
- users: user with group admins now have `wheel’ group associated with them, allowing them to us `su’ or `sudo’ (if configured)
- users: do not copy root’s hidden files while creating a new user home directory
Other news
First Experimental OPNSense Images With HardenedBSD
One month ago, we announced we were teaming up with OPNSense to provide HardenedBSD-flavored versions of their project. Work started with backporting
our work from 11-CURRENT to 10-STABLE. We worked with Franco Fichtner,
one of three people currently on the OPNSense core team, to enhance
their build scripts. We received hardware donations from Netgate and
Deciso. We fixed a number of bugs in secadm and backported Integriforce
to 10-STABLE. This month sure has been a busy one.
We're excited to announce today the availability of the first experimental build of OPNSense based on top of HardenedBSD. It features every one of our great exploitation mitigation features and is built with Integriforce baked right in. Most of the network-aware applications are compiled as Position-Independent Executables (PIEs). Please note that since this is our first ever experimental build, we have not worked out binary upgrade paths just yet. You will likely need to do reinstalls for future builds. You can backup your configuration prior to reinstallation and restore the configuration post-installation.
There are two flavors for download: a generic build and a build for the Netgate RCC-VE 4860. The generic build will work on most standard appliances. The Netgate RCC-VE 4860 has a special build due to needing custom serial console settings. If you're not using the Netgate RCC-VE 4860, the generic build is for you.
You can find the builds here. Please note that these builds are experimental. They are not meant for production use. But that still hasn't stopped us from using it in production, since we like to eat our own dogfood. ;)
UPDATE 11 Jun 2015 05:39 EDT: OPNSense has mirrored the generic builds here,
We're excited to announce today the availability of the first experimental build of OPNSense based on top of HardenedBSD. It features every one of our great exploitation mitigation features and is built with Integriforce baked right in. Most of the network-aware applications are compiled as Position-Independent Executables (PIEs). Please note that since this is our first ever experimental build, we have not worked out binary upgrade paths just yet. You will likely need to do reinstalls for future builds. You can backup your configuration prior to reinstallation and restore the configuration post-installation.
There are two flavors for download: a generic build and a build for the Netgate RCC-VE 4860. The generic build will work on most standard appliances. The Netgate RCC-VE 4860 has a special build due to needing custom serial console settings. If you're not using the Netgate RCC-VE 4860, the generic build is for you.
You can find the builds here. Please note that these builds are experimental. They are not meant for production use. But that still hasn't stopped us from using it in production, since we like to eat our own dogfood. ;)
UPDATE 11 Jun 2015 05:39 EDT: OPNSense has mirrored the generic builds here,
Stacked in Our Favor | BSD Now 93
We're at BSDCan this week, but fear not! We've got a great interview
with Sepherosa Ziehau, a DragonFly developer, about their network stack.
After that, we'll be discussing different methods of containment and
privilege separation. Assuming no polar bears eat us, we'll be back next
week with more BSD Now - the place to B.. SD.
NetBSD CI20 status update
I didn't really have much time to work on more hardware support on CI20 but it's been a while since the last post so here's what I've got:- drivers for on-chip ehci and ohci have been added. Ohci works fine, ehci for some reason detects all high speed devices as full speed and hands them over to ohci. No idea why.
- I2C ports work now, including the onboard RTC. You have to hook up your own battery though.
- we're no longer limited to 256MB, all RAM is usable now.
- onboard ethernet is supported by the dme driver.
The RTC is a bit funny - according to the manual there's a Pericom RTC on iic4 addr 0x68 - not on my preproduction board. I've got something that looks like a PCF8563 at addr 0x51, and so do the production boards that I know of. Some pins on one of the expansion connectors seem to be for a battery but I haven't been able to confirm that yet. Either way, since the main connector is supposed to be Raspberry Pi compatible any RTC module for the RPi should Just Work(tm), with the appropriate line added to the kernel config.
Some more work has been done under the hood, like some preparations for SMP support.
pfsense-tools is back on github
Some people prefer a web-ui for git. Rather than expose our
gitlab instance to the world via a web-ui, we’ve re-enabled access via
github.
The process remains the same. You will need to agree to two click-through agreements, first the Contributor License Agreement (either individual or corporate), then the actual license agreement, wherein you basically agree that our marks are valid, that you’ll give credit to the project, and that you won’t call the result pfSense, or anything else that is sufficiently similar to our trademarks to cause confusion.
If you’ve already been through that process, you’ve already been granted access to the team that can view the pfsense-tools repo on github.
If you haven’t put your github username in your pfSense portal profile, then we don’t know who you are on github, and the process won’t work.
Long-term, the goal is to eliminate the need for this repo. We don’t want to carry a set of discrete patches, and there are well-known examples of better build systems in the world. More on that in a future post.
The process remains the same. You will need to agree to two click-through agreements, first the Contributor License Agreement (either individual or corporate), then the actual license agreement, wherein you basically agree that our marks are valid, that you’ll give credit to the project, and that you won’t call the result pfSense, or anything else that is sufficiently similar to our trademarks to cause confusion.
If you’ve already been through that process, you’ve already been granted access to the team that can view the pfsense-tools repo on github.
If you haven’t put your github username in your pfSense portal profile, then we don’t know who you are on github, and the process won’t work.
Long-term, the goal is to eliminate the need for this repo. We don’t want to carry a set of discrete patches, and there are well-known examples of better build systems in the world. More on that in a future post.
Code stuff
Interesting Articles
Wallpaper of the week
from https://www.br0tkasten.de/?page=18
0 comments:
Post a Comment