Yes, I get it, you're a big fan of argument-by-authority. Try something new for a change: Think for yourself *gasp*, and explain why exactly the FAQ encourages this, and the security implications of it.
(besides, that's not that much more secure, since the ports tree itself isn't signed, either).
Checking out the ports tree via cvs+ssh means i can be reasonably sure that i get in fact the right thing, including distfile hashes.
So yeah, it is much more secure.
As for the ``but it's so hard to compile ports'' argument, i have to admit i was only infering from what I'm used to from Net- and FreeBSD.
So, what exactly is the big deal with compiling ports on OpenBSD? Now i'm honestly curious.
And why would you do that? Going that way you're easily MITM'ed.
Can you give some better reason than 'everyone does it'?
Why exactly would you prefer an insecure transmission channel over a reasonably secure one, for the software you install? How does that even remotely fit the OpenBSD mindset?
Even for the kernel itself, it is highly recommended for non-developers to only run the binary snapshots.
This sounds just as stupid, and I'm tempted to believe it's only recommended to raise the signal-to-noise in crash reports. Crash dumps from custom kernels are harder to analyze for other developers than if the generic one was used.
What the heck?
What you say makes sense, but it's wrong.
Looking closer, the FAQ is wrong here.
A "package" is defined as a binary executable, and a "port" is defined as the source (using OpenBSD's terminology).
Yes. This is about who builds the package, though. It's a bit vague terminology, but for my purposes, 'using a port' means building it yourself and installing the resulting package, while 'using a binary package' means fetching the prebuilt package from somewhere else.
With this out of the way..
"In general, you are highly advised to use packages over building an application from ports.
Well frankly I have no idea why there's such utter BS in the FAQ.
It essentially tells us we're ``highly advised'' to fetch unsigned tarballs over plaintext ftp, when the alternative way is the admittedly antiquitated but at least secure cvs-over-ssh checkout.
Every security-minded person with half a brain can figure.
Maybe using a binary package isn't the actually right/secure way, but it definitely is "considered" to be "the right away to do things", exactly in contrast to your statement.
Your argument is essentually argument-by-authority, although I admit I usually trust official FAQs, too. This seems really odd.
On the upside, when signify is done, they at least don't need to update the FAQ, since then using binary packages will be equivalently secure.
Admittedly I was only inferring from NetBSD.
Reading the OpenBSD FAQ, it in fact seems to recommend using binary packages, unsigned, transmitted over an insecure channel, which, frankly is retarded and should be fixed, unless signify is really really near.
Its dead to me. I've turned my back on more than one project (security software, no less) because the author demanded I take a leap of faith with unsigned code.
Whatever you're talking about, it seems to have little to do with the matter being discussed.
So your statically linked gpg binary is smaller than my dynamically linked gpg binary on the closely related NetBSD.
That does not seem legit, please run the commands I ran, on the not-upx'ed binary and post the results.
Wrong. Using binary package is just considered not the right way to do things, in OpenBSD land. What you do is, check out the source repository, which does make sure the data you get hasn't been tampered with, then build it from source. For mass deployments, you can then create binary packages from the result (secure distribution to other machines is your job, however. although that typically isn't much of a concern since it usually happens on the local network.
On the flip side in the real world I haven't used a single piece of advanced mathematics that I endured during my degree. We often joke about how everyone should brace themselves because one of the engineers is reaching for the square root button, but the reality is much of the maths has been replaced by advanced simulation software.
With simulation software able to calculate all things RF, analogue impedances, filters, interactions between different parts of a circuit due to inductive coupling etc. what is there left to do for an EE that actually requires the practical application of this maths? The only person I know who uses it works for a company which sells simulation software.
It's still important to know said math so you can check the results of simulation for plausibility. Otherwise you're blindly relying on that software being flawless.
I said 'essentially', and my point is that technically there is no reason to replace your OS with something completely 'new' (read: functinally equivalent yet looking differently) every other year.
The choice of operating system isn't really relevant here...
Well TrueCrypt kind of implies Windows, as Linux people tend to rather use cryptsetup/LUKS/dm-crypt, BSD people use geli/cgd and Apple people use something shiny
Slashdot Mirror
Yes, I get it, you're a big fan of argument-by-authority.
Try something new for a change: Think for yourself *gasp*, and explain why exactly the FAQ encourages this, and the security implications of it.
(besides, that's not that much more secure, since the ports tree itself isn't signed, either).
Checking out the ports tree via cvs+ssh means i can be reasonably sure that i get in fact the right thing, including distfile hashes.
So yeah, it is much more secure.
As for the ``but it's so hard to compile ports'' argument, i have to admit i was only infering from what I'm used to from Net- and FreeBSD.
So, what exactly is the big deal with compiling ports on OpenBSD? Now i'm honestly curious.
Can you give some better reason than 'everyone does it'?
Why exactly would you prefer an insecure transmission channel over a reasonably secure one, for the software you install? How does that even remotely fit the OpenBSD mindset?
Even for the kernel itself, it is highly recommended for non-developers to only run the binary snapshots.
This sounds just as stupid, and I'm tempted to believe it's only recommended to raise the signal-to-noise in crash reports. Crash dumps from custom kernels are harder to analyze for other developers than if the generic one was used.
And the CVS transport used in OpenBSD is.....? *drumroll*
What the heck? What you say makes sense, but it's wrong.
Looking closer, the FAQ is wrong here.
A "package" is defined as a binary executable, and a "port" is defined as the source (using OpenBSD's terminology).
Yes. This is about who builds the package, though. It's a bit vague terminology, but for my purposes, 'using a port' means building it yourself and installing the resulting package, while 'using a binary package' means fetching the prebuilt package from somewhere else.
With this out of the way..
And, I quote, http://www.openbsd.org/faq/faq15.html#PkgVsPorts
"In general, you are highly advised to use packages over building an application from ports.
Well frankly I have no idea why there's such utter BS in the FAQ.
It essentially tells us we're ``highly advised'' to fetch unsigned tarballs over plaintext ftp, when the alternative way is the admittedly antiquitated but at least secure cvs-over-ssh checkout.
Every security-minded person with half a brain can figure.
Maybe using a binary package isn't the actually right/secure way, but it definitely is "considered" to be "the right away to do things", exactly in contrast to your statement.
Your argument is essentually argument-by-authority, although I admit I usually trust official FAQs, too. This seems really odd.
On the upside, when signify is done, they at least don't need to update the FAQ, since then using binary packages will be equivalently secure.
Admittedly I was only inferring from NetBSD.
Reading the OpenBSD FAQ, it in fact seems to recommend using binary packages, unsigned, transmitted over an insecure channel, which, frankly is retarded and should be fixed, unless signify is really really near.
eh, gpgv
good call, I wasn't aware of gogv. It's 340K, but uses the same shared libs
$ gpg --version
gpg (GnuPG) 1.4.15
(good call, broken_chaos)
Its dead to me. I've turned my back on more than one project (security software, no less) because the author demanded I take a leap of faith with unsigned code.
Whatever you're talking about, it seems to have little to do with the matter being discussed.
Those "probably" (read: as is the case for any other OS) come with the installation media, which is an entirely different matter.
$ ls -lh `which gpg` /usr/pkg/bin/gpg
/usr/pkg/bin/gpg: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for NetBSD 6.1.2, stripped
/usr/pkg/bin/gpg: /usr/lib/libintl.so.1 /usr/lib/libgcc_s.so.1 /usr/lib/libc.so.12 /usr/lib/libz.so.1 /usr/lib/libbz2.so.1
-rwxr-xr-x 1 root wheel 892K Jan 19 06:09
$ file !$
file `which gpg`
$ ldd !$
ldd `which gpg`
-lintl.1 =>
-lgcc_s.1 =>
-lc.12 =>
-lz.1 =>
-lbz2.1 =>
$ uname -rsm
NetBSD 6.1.2 amd64
So your statically linked gpg binary is smaller than my dynamically linked gpg binary on the closely related NetBSD.
That does not seem legit, please run the commands I ran, on the not-upx'ed binary and post the results.
Wrong. Using binary package is just considered not the right way to do things, in OpenBSD land.
What you do is, check out the source repository, which does make sure the data you get hasn't been tampered with, then build it from source.
For mass deployments, you can then create binary packages from the result (secure distribution to other machines is your job, however. although that typically isn't much of a concern since it usually happens on the local network.
IOW, your comment is pure BS.
Every Ask Slashdot gets a comment pointing out that it's the dumbest Ask Slashdot ever, I know.
This time, it's really, really the case.
You seem to have missed ze point here. (hint: try reading GGGP, then GGP, then GP, then your post)
because it's the path of least resistance? No
Yes.
On the flip side in the real world I haven't used a single piece of advanced mathematics that I endured during my degree. We often joke about how everyone should brace themselves because one of the engineers is reaching for the square root button, but the reality is much of the maths has been replaced by advanced simulation software.
With simulation software able to calculate all things RF, analogue impedances, filters, interactions between different parts of a circuit due to inductive coupling etc. what is there left to do for an EE that actually requires the practical application of this maths? The only person I know who uses it works for a company which sells simulation software.
It's still important to know said math so you can check the results of simulation for plausibility.
Otherwise you're blindly relying on that software being flawless.
Actually, modding it informative would have been funnier than modding it funny
I said 'essentially', and my point is that technically there is no reason to replace your OS with something completely 'new' (read: functinally equivalent yet looking differently) every other year.
Your OS 20 years ago didnt have protected memory
Perhaps /yours/ didn't.
, ASLR, or a journaling filesystem, to name a few big ones.
Those are 'a few big ones' of what? Big reasons that you need a 'new OS'? Dammit you're making me facepalm.
well you're doing it wrong then
Sure. My point was, nobody actually uses it outside the Windows world.
Except that commercial software doesn't have near that long of a lifespan.
FTFY. Now get of my lawn.
Except stuff like device drivers, my OS is essentially the same it was 20 years ago.
Care to name actual reasons for why you would want/have to change your OS every other year?
The choice of operating system isn't really relevant here...
Well TrueCrypt kind of implies Windows, as Linux people tend to rather use cryptsetup/LUKS/dm-crypt, BSD people use geli/cgd and Apple people use something shiny
PotPlayer for video, foobar2000 for audio.
Both sound like typical windows software.
Anything else is just silly.
You should widen your horizon a bit.