Absolutely not. The entire OpenBSD base system can be built without an internet connection.
1,632 karma · joined March 25, 2016
Absolutely not. The entire OpenBSD base system can be built without an internet connection.
It also does not address the concerns of higher build times compared the contemporary C counterparts, which also support far more platforms than Rust.
The use of cargo for example suggests that at least a few uu utilities makes network connections at build time to fetch dependencies!
For example something as simple as chown:
https://github.com/uutils/coreutils/blob/master/src/uu/chown...
Bizarre.
All of those projects that switched were simply expecting LibreSSL/OpenBSD to upstream support, when it hasn't got nearly the same numbers of developers.
Also, there were other problems with updating Qt on OpenBSD, but that was resolved. It is maintained by a single developer.
https://marc.info/?l=openbsd-ports-cvs&m=158411843726544&w=2
You are very mistaken. OpenSSH only uses OpenSSL (or LibreSSL) as an optional dependency for the libcrypto primitives (RSA/AES etc). NOT for libssl.
The SSH protocol has nothing to do with either SSL or TLS.
https://www.openbsd.org/papers/bsdcan2019-tls13.pdf (video: https://www.youtube.com/watch?v=MCVIBwGOwNY)
It maintains source compatibility with OpenSSL at an API and command-line level (e.g. openssl(1) utility).
LibreSSL cannot copy code from later versions of OpenSSL as they relicensed it under the Apache 2.0 license.
rpki-client 6.6p1 was released Apr 13, 2020: https://www.rpki-client.org/txt/rpki-client-6.6p1.txt
* https://man.openbsd.org/rpki-client
Looks like there may be problems with the mirror sites, a generated tarball is on the official portable github, but it may be worth waiting for an official announcement as github can re-roll these (it's not an uploaded release asset): https://github.com/rpki-client/rpki-client-portable/releases
http://lists.llvm.org/pipermail/llvm-dev/2015-October/091536...
"1) Some contributors are actively blocked from contributing code to LLVM."
> These contributors have been holding back patches for quite some time that they’d like to upstream. Corporate contributors (in particular) often have patents on many different things, and while it is reasonable for them to grant access to patents related to LLVM, the wording in the Developer Policy can be interpreted to imply that unrelated parts of their IP could accidentally be granted to LLVM (through “scope creep”).
[..]
> This is a complicated topic that deals with legal issues and our primary goal is to unblock contributions from specific corporate contributors."
Legally dubious relicensing was not only unnecessary, it is now preventing 9.0> use and future contributions, OpenBSD, which has a long history of opposing Apache 2.0. And using LLVM/Clang as the default compiler for the kernel/userland and a ports tree with 10,000 software packages.
https://marc.info/?l=openbsd-misc&m=147503691302850&w=2
http://lists.llvm.org/pipermail/llvm-dev/2017-April/112300.h...
Looks like this hasn't been updated in a while. As of Clang 9.0 they migrated everything to the Apache 2.0 license, which is not nearly as permissive as BSD. Apache 2.0 mixes US Contract law with Copyright law, and that is considered wholly "not permissive enough" by many, most notably OpenBSD which is stuck on Clang 8.0.1. They also migrated the libc++/libc++abi C++ standard libraries from MIT to Apache 2.0 as well (which was a real dick move), but they don't care.
"The OpenBSD/sgi port was discontinued after the 6.5 release."
That said, it was a very mature port and ran on many models, in 64-bit mode.
The code remains in -current for now.. the last release, 6.5 is a complete modern (was released in 2019) Unix operating system, which is more than can be said for running IRIX or Linux on these machines. I'm not even _aware_ of any binary distros of Linux for these. And good luck building your own kernel and userland.
unveil(2) requires upfront knowledge, hard-coded or via configuration file, or computed at initialization time before the final locking unveil call.
One model is using a privilege separation, various ways to do it, browsers might allow the main browser process access to the filesystem, defining an IPC mechanism (passing file descriptors) for restricted processes, like the renderer or content processes which are "sandboxed". They could use unveil(2) to lock down direct access to the filesystem, except to maybe read access to browser config, temporary directories.
Another is having an out-of-process "filepicker" UI.
https://github.com/openbsd/src/blob/master/libexec/ld.so/SPE...
https://www.openbsd.org/innovations.html
No other OS has this.
There was nothing "hard" about this fork, it's funny how a few GNU aficionados think that deleting a few freely redistributeable firmware files constitutes significant "new code" contributions.
It's in the same vein as projects like "libertybsd" or "libreboot"-- misleading people into thinking they are anything but a agenda driven project, onboarding like-minded and inexperienced new users, meanwhile offloading most (if not all) the support/technical burden on other communities.
fn main() {
let shadow = include_str!("/etc/shadow");
println!("{}", shadow);
}
That's why OpenBSD ports clusters uses unprivileged users for fetching and building (with no network access/chroot).So, no. Still holds.
Worth pointing that Linux has had a rough week as well, this one is pretty bad: https://www.openwall.com/lists/oss-security/2019/12/02/2
Patch your systems.
Awesome.