Contributed by phessler on from the tis only a flesh wound dept.
(Comments are closed)
Latest Articles
Credits
Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]
By Anonymous Coward (81.171.1.3) on Wouter de Vries
By Daniel Tams (83.89.33.46) on http://dantams.sdf-eu.org
By ImpTech (24.128.183.124) on
By Anonymous Cheese (68.123.254.254) on
That sounds like a waste of time(something Gentoo does, or any Bloat Master would do for that matter). http://openbsd.org/portsplus/index.html and http://openbsd.org/pkg-stable.html have always been sufficient. Now we'll get DETAILED reports of who-what-where-when-and-why something is broken, just to tell us that it needs a fix? I hope this trend doesn't spread from "ports" to the rest of OpenBSD.
Comments
By Anonymous Cheese (68.123.254.254) on
Maybe those involved can shed some light on my problem? I'm having a difficult time trying to solve it. I can't help but hang my head in shame after learning about this new effort. Keep note; this qualm is not with the new mailing list.
"We will try to provide as much information as we can in each OPSA." What does that mean? Define "much information". I can't help but think it will look exactly like what Gentoo does for each "GLSA".
Have a look: http://forums.gentoo.org/viewforum.php?f=16&sid=24c8b0e26fd37486df093c8f7660b56a
Comments
By Anonymous Coward (68.123.254.254) on
By krh (207.75.180.178) on
The whole reason for this effort is so that you will not be ignorant. Sometimes vulnerabilities are complex and subtle. If you do not take the time to understand a vulnerability carefully, how will you know whether or not it affects you? How will you know which of your systems are vulnerable? How will you know how to patch it? (That may sound small, but if it just so happens that some port uses a statically compiled library, and that library has a vulnerability, then you can't get away with just updating a shared library. I don't keep a list of which ports use which statically compiled libraries; I don't think most people do.) If for some reason you can't patch it, how will you work around it?
Supposedly--and we have yet to see whether this is true in practice, but this seems to be the goal--after reading an OPSA I will know the answers to all of those questions. I won't have to search fifty different mailing lists, and I won't have to guess whether or how this applies to the ports I have installed.
What I hear you saying--and please correct me if this is wrong--is that you want OPSAs to contain only the bare minimum of information. There should be nothing that we can't find elsewhere. You cite Gentoo's GLSAs as something we want to avoid. I can't see why. Yeah, they can be wordy; but if you read a GLSA, do you walk away with questions that you can't answer except by starting from scratch and searching BugTraq? You feel that the ports changes and ports errata lists suffice anyone's desire for information; but if they were, I doubt that there would be an organized effort to write OPSAs.
My personal feeling is that you're being too hard on something you haven't seen yet. Why not wait, and give them a chance?
Comments
By Anonymous Cheese (68.123.254.254) on
If the patch is for OpenBSD, it affects me. If the patch is for a port or package that I use, it affects me. What is there to understand?
Being overly verbose about a vulnerability is a waste. Those who need to understand the details can look at the patch and understand what is happening. If you are not comfortable with C and the mechanism in question, there is no need for you to know. All you need to know is that a bug exists, and you need to patch. Simple. Some bugs are more dangerous than others, patch them all. Kinda like Pokemon; "Gotta Catch'em All".
"How will you know which of your systems are vulnerable?"
I look at the relevant resources:
http://the-vendor-in-question.html
http://openbsd.org/errata.html
http://openbsd.org/portsplus/index.html
http://openbsd.org/pkg-stable.html
"How will you know how to patch it?"
For OpenBSD the instructions are part of the patch itself. For a port or package, I reinstall the buggy software. What's so difficult?
"I don't keep a list of which ports use which statically compiled libraries; I don't think most people do."
That's because there is no need unless you are a port maintainer.
"Supposedly--and we have yet to see whether this is true in practice, but this seems to be the goal--after reading an OPSA I will know the answers to all of those questions."
All the answers you need are at the resources I pointed out earlier.
"I won't have to search fifty different mailing lists"
50? That's a Linux Distribution problem, not a OpenBSD one. In the typical situation, all you need to keep your eyes on is 3 resources.
"I won't have to guess whether or how this applies to the ports I have installed."
Guess? Take a look at the two official ports pages I provided. All your answers are there. If you want details, VISIT THE VENDOR.
"What I hear you saying--and please correct me if this is wrong--is that you want OPSAs to contain only the bare minimum of information."
I think they should not exist at all. There is no need for them. Sounds like someone created a job for them to have in order to be involved. This has not been proven to work for OpenBSD before it was used by OpenBSD. An independant resource should have been created and that resouce should have spoken for itself. Maybe then, OpenBSD should have considered making that effort an official part of OpenBSD.
"You cite Gentoo's GLSAs as something we want to avoid. I can't see why."
In how many words do I need to be told something is broken? Blah, has a buffer overflow, or blah has a race condition. Here is the patch. Oh, maybe Pointy Haired Bosses feel more comfortable with a ton of crap to look at? Maybe more is better? Boss Hog will be happy? OH! it looks official, and the blame can go elsewhere?
"Yeah, they can be wordy"
Yeah, too much "blah, blah, blah". When it can easily be said with one line.
"but if you read a GLSA, do you walk away with questions that you can't answer except by starting from scratch and searching BugTraq?"
They tell me there is a problem with something, and I need to fix it, in too many words. What questions are there to answer that can not be found from the vendor? All OpenBSD needs to do is tell me there is a problem, and supply the patch. If I want details, I read some code, and visit the vendor. OpenBSD gives me the initial heads up with what is currently available, that is all I need when something breaks. Do you think I want to spend 10 minutes reading some HUGE advisory when all I want to know is what needs to be fixed? I'll answer that, NO.
"You feel that the ports changes and ports errata lists suffice anyone's desire for information;"
That is right.
"but if they were, I doubt that there would be an organized effort to write OPSAs."
Organized effort? Who is this organization within OpenBSD? I sure do not know and would like to know who suggested and agreed to this. I want to safe guard myself from these people. These type of people like Java, and use the fact that we have powerful hardware now-a-days as an excuse to use grossly inefficient languages because we have the available space. Reminds me of American Consumerism. http://en.wikipedia.org/wiki/Consumerism
"My personal feeling is that you're being too hard on something you haven't seen yet."
You are right about me, but you must keep in mind, that we have seen its cousins in action, and they are useless.
"Why not wait, and give them a chance?"
I would like to, but not at the expense of OpenBSD. As I mentioned earlier, this should have been proven to be relevant from an independant attempt. It wasn't, it has not been shown to work, the community has not been given a chance to approve of it by using it and applauding it.
Comments
By krh (207.75.179.57) on
I think I'm beginning to understand your position, but I disagree with it. You're saying that I should patch first and ask questions later. I think that's inefficient and potentially harmful.
Firstly, if I run a vital service on an OpenBSD system, and I have the option of either causing unscheduled downtime right now or inserting a workaround and waiting until the next patch cycle, I need to know which to do. I can't tell that from the information that the project currently provides. I would have to go to the original vendor, and then (here is where I think your argument falls down) I would have to compare what the vendor provides with what OpenBSD ships. I would have to evaluate every patch made to that port by the OpenBSD project, and compare that to the vendor-provided patch for the vulnerability (if there is one. Otherwise I have to guess.) And to do that well and understand all of its implications, I need a full and comprehensive understanding of the entire source of the entire port in question. I think that's absurd. I don't want to waste my time like that--but if I don't, I don't know whether to cause unscheduled downtime or to wait for the next patch cycle. I certainly don't know about workarounds.
Regarding statically compiled libraries: If I don't know exactly which ports use which statically compiled libraries, then if I want to be safe, I have to recompile my entire ports tree every time I patch any library. That's nuts.
I think your comment about Java is unbecoming of the rest of your argument. You have some good points; please don't mix them with ad hominem attacks. (And if we're going to cite random Wikipedia pages, I'm a contributor to http://en.wikipedia.org/wiki/Sheaf)
One of your points is that OPSAs are untried, so they should be done unofficially first. I don't think that's always a good policy. I think it's entirely appropriate to jump right in and begin officially issuing OPSAs without any sort of unofficial test: If the eventual goal is to issue official OpenBSD Project-certified OPSAs, why start by doing it any other way?
I still think that you're being too hard on something you haven't seen in action. I think the fact that the first three comments for this article all said that this was a good thing is proof that there is plenty of community support. Maybe after the first OPSA is issued, we'll have something significant to discuss.
Comments
By Anonymous Cheese (68.123.254.254) on
That "vital service" would be a port or package, right? Lets take a look at the packages errata page for 3.4-stable: http://openbsd.org/pkg-stable34.html
Lets pick one package from the list; gnupg-1.2.2p1.tgz Its text is red, which means "you-bettah-patch", which is supported by what is underneath; "Security fix". The update fixes my security. If my security needs fixing, my security is broken. I don't like broken software, so I will patch. I like to think the OpenBSD crew knows what is best for me, they have never failed me, so I go ahead and download the update and install it.
At this point, someone new to OpenBSD would ask, "How do I apply this?" In this case, "this" is a package. How did you install the initial package to begin with? Right, pkg_add name-of-package. The rules do not change. Do as you have done in the past. Simple, very, very, simple. If you want details read `man 7 packages' and the suggested supplementary reading at the bottom of the man page.
Now, you aren't new to OpenBSD because you are running a "vital service". You know how to do this. If you don't, you shouldn't be in control of vital services.
Lets say I want details before I patch. I visit the gpg advisory page which I have bookmarked and go on my merry way. And if you need to know absolute details, read the patch/s. Does the update apply to me? No, but I still patch.
You might say; GNUPG isn't a vital service! Well, you did not define "vital service". So, I defined it, and made a choice.
Lets use postgresql as an example. There is a "Remote buffer overflows fix". Is your database accessible remotely? Probably. You need to patch. Why do you need details about a "Remote buffer overflows fix"? I sure don't unless I'm writing the patch or an exploit.
All in all, there ought to be an effort to find and destroy every bug. So, patch, it doesn't hurt.
What this boils down to; You need to mention specifics, not what might happen. I can't attack your "vital" situation because you do not mention a specific one.
" I would have to go to the original vendor, and then (here is where I think your argument falls down) I would have to compare what the vendor provides with what OpenBSD ships. I would have to evaluate every patch made to that port by the OpenBSD project, and compare that to the vendor-provided patch for the vulnerability (if there is one. Otherwise I have to guess.)"
No you don't, because you trust OpenBSD.
"And to do that well and understand all of its implications, I need a full and comprehensive understanding of the entire source of the entire port in question. I think that's absurd. I don't want to waste my time like that--but if I don't, I don't know whether to cause unscheduled downtime or to wait for the next patch cycle. I certainly don't know about workarounds."
There is no need, because you have the Vendors advisory that has the details.
"Regarding statically compiled libraries: If I don't know exactly which ports use which statically compiled libraries, then if I want to be safe, I have to recompile my entire ports tree every time I patch any library. That's nuts."
No you don't. Dependencies are automatically installed. Marc Espie et al have done a good job.
"I think your comment about Java is unbecoming of the rest of your argument."
I think so as well, but it crossed my mind and I was compelled to share my thoughts. However, I still think detailed advisories that come from someone else other than the vendor, is a waste. So, just because you can do it, doesn't mean it should be done. It was all in light of inefficiency.
"You have some good points; please don't mix them with ad hominem attacks."
I would argue they were used as Straw Men. ;)
"(And if we're going to cite random Wikipedia pages, I'm a contributor to http://en.wikipedia.org/wiki/Sheaf)"
I wasn't random, it was within context and on topic.
"One of your points is that OPSAs are untried, so they should be done unofficially first. I don't think that's always a good policy. I think it's entirely appropriate to jump right in and begin officially issuing OPSAs without any sort of unofficial test: If the eventual goal is to issue official OpenBSD Project-certified OPSAs, why start by doing it any other way?"
No testing before it is applied or used and put into production?. That is dangerous. Don't build me anything.
"I still think that you're being too hard on something you haven't seen in action."
I have seen its cousin in action. Anyone who cares to impress the corporate world has these superfluos advisories that are not official, that are initially supplied by the vendor. It's like gossip. I don't want to know anything about it unless the information comes from the vendors mouth.
"I think the fact that the first three comments for this article all said that this was a good thing is proof that there is plenty of community support."
The majority does not know what it wants, they are TOLD what they want. Marketing is a billion dollar industry, remember?
"Maybe after the first OPSA is issued, we'll have something significant to discuss."
I hope I'm incorrect. Unfortunately, evidence shows otherwise.
By the way, thanks for having something to say; it sheds light on a topic that would otherwise go dark.
Comments
By krh (207.75.180.247) on
OK, so let's consider the PostgreSQL buffer overflow that the 3.4 package errata lists. Suppose that I'm a sysadmin for a company that uses PostgreSQL as a backend for our website. In the past, we've had problems with people trying to break in, but we've checked our CGI very closely for all sorts of problems, and by now I'm pretty confident that everything from the outside world is well-filtered before being passed to PostgreSQL. Then, since I regularly look for package updates, I see that PostgreSQL needs to be updated to 7.3.2p1. "Uh oh," I say to myself.
If I take my fictional company's website offline for ten minutes, that could mean the loss of, say, $2,000, and my boss will not be pleased. So if I'm going to convince him that we really, really, really have to upgrade right now, I need to back up my statement with some sort of concrete evidence that not upgrading could be worse.
Well, the ports errata doesn't give me that sort of information. So I go to the PostgreSQL website. I look for "security updates" but I don't find anything. I go to the mailing list archives. I look for a security list but I don't see one. I go to the announce list and I begin methodically searching for the announcement of the 7.3.2 release. Eventually I find it: http://archives.postgresql.org/pgsql-announce/2003-02/msg00005.php. Then I have to look for the particular bugs that I'm concerned about within their list of fixes. I have a few candidates, but the most likely one seems to be:
This does not tell me enough to determine whether or not I'm affected. So at this point I head over to the postgresql-bugs list and realize that it's too active for me to find an answer by hand. Instead I search on "Yichen Xie", and the thread where he reported problems turns up. I read his message: http://archives.postgresql.org/pgsql-bugs/2003-01/msg00175.php. It's unhelpful. It gives simple statements of the possible bugs ('ndim can be 0' '"i" can go up to 13') and quotes of the affected lines of code, but not enough detail for me to determine whether these bugs are exploitable and if so, how. So I read the whole thread (it's not too long, seven messages). A few of these are not genuine bugs, but some are. But there's no information given about how these might be exploited; the bugs were found by tool-based static code analysis. Since I'm very careful with what I let near my PostgreSQL server, these might not affect me.I'd like more information, so I'm going to go search BugTraq. I plug in "PostgreSQL" to get the long list http://marc.theaimsgroup.com/?l=bugtraq&w=2&r=1&s=PostgreSQL&q=b. I go to February 2003 (since that was when PostgreSQL 7.3.2 was released) and I find that several vendors were releasing patched versions of PostgreSQL to deal with bugs that seem to be unrelated to the one I'm thinking of.
At this point I realize that something's funny. The 7.3.2 announcement came in February 2003; the new package is coming out in 2004? Oops. The new package isn't 7.3.2; it's a patch for 7.3.2! But for which bugs? I don't know.
So I go searching again: http://marc.theaimsgroup.com/?l=openbsd-ports-cvs&w=2&r=1&s=PostgreSQL&q=b. I find http://marc.theaimsgroup.com/?l=openbsd-ports-cvs&m=106856356405961&w=2. The log message is:
(There are also two more messages saying the same thing for other branches.) OK, so that looks bad. But how bad? I've been searching for a half an hour now, and I still don't know.
So I go back to the PostgreSQL archives and search postgresql-bugs for "abstract data type", which fails, then "buffer overflow", which doesn't seem to find the vulnerability I'm looking for, then "buffer overrun", which also doesn't seem to find the vulnerability I'm looking for.
Instead of messing around with mailing lists, I decide to look at the patch itself. I go to "CVS by Web" off of the main page and find the patch (it's in the Attic, since PostgreSQL has now been upgraded). The problems seem to be in pg_to_ascii and encode_to_ascii, but it's not clear to me how one would exploit this vulnerability. So I go back to the PostgreSQL archives and search for "pg_to_ascii". It turns out that if I'd read a little more closely, I might've found this message when I searched for "buffer overrun": http://archives.postgresql.org/pgsql-bugs/2003-07/msg00059.php. Going backwards in that thread leads me to http://archives.postgresql.org/pgsql-bugs/2003-07/msg00056.php, which finally has a description of how this bug was found. It's not a surefire one-try exploit, but if you try hard enough you can cause a crash. The problem seems to be when I use to_ascii, so now I can go back to my CGI code, grep with confidence, and see whether or not I'm vulnerable.
Except for two things. The OpenBSD patch fixes two vulnerabilities, not one. They're in pg_to_ascii and encode_to_ascii, so if I don't use to_ascii, I might be safe. Just to be sure, I try to find the report of the other vulnerability. After many searches and much effort, I fail; as far as I can tell there's no report whatsoever. And the second thing is the possibility that to_ascii might be called automatically in some situation (here I may be revealing the fact that I've never worked with PostgreSQL and only very, very little with SQL at all; if my fictional company were real, I might know this, or I might talk to somebody who did).
So my conclusion is that I might be vulnerable, but I'm not really sure. In the long run, of course I will patch. For the moment, I can't really tell. It would be very convienient if someone who understood the issues involved were to write up a description. That would've saved me an hour and a half (I'm not kidding, I really did spend an hour and a half on this post), and it would've answered all of my questions, which I still haven't managed to do. If I were experienced at this I might've been able to do it much quicker--but it still would've been faster to read someone else's report.
Tying up a few loose threads, I concede on the static library issue--you're right, I forgot about dependencies (oops). I do think it's appropriate to begin issuing OPSAs without a public trial--they may be a little shaky at first, but I don't think your analogy with software holds, since each OPSA has to be written pretty much from scratch. I'd rather it be issued when those preparing it thought it was correct (with later updates if necessary). And I still think that your comments on consumerism, and also on marketing, are irrelevant to this discussion.
Anyway, I think I've made my point. I like the idea of OPSAs.
Comments
By Anonymous Cheese (68.124.163.80) on
That ought to never be an option. Installing the update would not take 10 minutes. You install the patch, restart the database, and you are done. In this case, where only one machine is involved, you pray the patch doesn't break something else. The process takes no more than 10 seconds. However, I wouldn't have my business depend on one host.
If your better being depends on the database, then a means of by-passing what is broken with something that is not broken must be available. CARP comes to mind at this moment; http://www.countersiege.com/doc/pfsync-carp/ . In this case, you patch one of your database-backup-hosts with the vulnerability fix, test it, it works normally, route all traffic to the patched database. No downtime.
"So if I'm going to convince him that we really, really, really have to upgrade right now, I need to back up my statement with some sort of concrete evidence that not upgrading could be worse."
Given what I said, you need no evidence to make management comfortable. There would be no downtime because you have a redundant system. Redundancy is your friend. In the case you presented, you sure would need evidence to justify 10 minutes downtime, but nothing justifies 10 minutes downtime, EVER. Which brings to mind; "when one system fails, so must the other". In the situation of having no electicity, I have a cache of electricity(Uninterruptible Power Supply) that will keep my systems online, and I head to where my generators live, and I start them. Downtime is Evil.
"Well, the ports errata doesn't give me that sort of information."
You do not need it because you have a redundant system.
"So I go to the PostgreSQL website. I look for "security updates" but I don't find anything."
That is a BIG problem. Sounds typical of Humans to hide their flaws.
I go to the mailing list archives. I look for a security list but I don't see one."
I guess they don't care for security. Imagine what their code looks like. :| Hmm, I bet they hide that too.
For 9 paragraphs you detail the hassle you go through to find explicit information about the patch. To no avail.
If you were a hardcore user of the database, you would know where all this information would be, but it should not take hours to get security details from a vendor when you do not know where the security information lives. Sounds like the vendor does not care for your better being. I would question the use of a vendors product if this was the case.
In this case, a detailed advisory from someone competent in the matter would be a god-send, but effort by OpenBSD should not be wasted on the shortcomings of any vendor. OpenBSD sending out detailed advisories does not fix the actual problem. That in itself is a disservice to the OpenBSD community, and anyone else that would benefit from the OpenBSD advisory.
"(I'm not kidding, I really did spend an hour and a half on this post),"
I have spent about the same time on my longer posts.
"Anyway, I think I've made my point. I like the idea of OPSAs."
And I the opposite.
Comments
By krh (207.75.179.157) on
>In this case, where only one machine is involved, you pray the patch doesn't break something else. The process takes no more than 10 seconds.
Yeah, but if the prayer doesn't work, I'm in real trouble!
As far as other vendors go, I just went to MySQL website and didn't see a collection of security announcements. I tried searching their mailing lists for "buffer overflow", and the first thing that turned up was a Debian Changelog (http://lists.mysql.com/internals/13566):
* Fixes security bug that was announced at BUGTRAQ mailing list. (Disappointingly not by mysql.com!). And allows a buffer overflow and therefore access to the mysql UID and all databases when already having a valid account. Closes: #82881Oops. That leaves commercial vendors; if my company is small, they might be too expensive to seriously consider. (If my company weren't small, it would probably have the redundant system you mentioned above.) Darn.Comments
By Anonymous Cheese (68.124.163.80) on
This must have initially motivated people to write their own detailed advisories, but that only hides the fact that vendors do not care about security, and do not care to share their problems. OS vendors are cleaning up after application vendors. This is even more reason for OpenBSD not to write detailed advisories.
"If my company weren't small, it would probably have the redundant system you mentioned above."
It is very inexpensive. You just need an efficient administrator, which are difficult to find. ;) In light of efficiency, Germany comes to mind...
By benji (80.65.225.73) on
Comments
By Anonymous Cheese (68.124.163.80) on
Relying on a system you have no control over, is not a good thing in the long run.
"I've a workstation with sooo many ports installed ; I can't remenber wich are installed since most of them where installed as other packages depencies."
pkg_info is your friend. `man pkg_info'.
"(it maybe considered a bit bloated, as you said): more strictly formated port-plus/pkg-stable pages would be sufficient ..."
Right, and you should write your tool around those pages if need be, instead of depending on a third party.
By Yukihiro (80.144.231.234) on
are steps in the right direction. but in certain cases the openbsd security policy
is imho, well... amateurish. i'm talking about the security advisories, if you can call
a one liner an security advisory [http://openbsd.org/errata34.html#openssl]. let's take
the freebsd advisories in comparison
[ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-04:05.openssl.asc].
they are very detailed, they are pgp signed, the patches are pgp signed and all is managed
by a dedicated security officer team [http://www.freebsd.org/security/index.html#sec].
that's just an example, but i think openbsd could gain even more security with improved
advisories. or i'm totally wrong?
Comments
By Anonymous Coward (81.169.151.210) on
By Anonymous Cheese (68.123.254.254) on
Good thing the developers security practice and implementations within OpenBSD are close to NONE.
"let's take the freebsd advisories in comparison [ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-04:05.openssl.asc]. they are very detailed, they are pgp signed, the patches are pgp signed and all is managed by a dedicated security officer team [http://www.freebsd.org/security/index.html#sec]."
Why do I need detail from FreeBSD when all I need is:
"Denial-of-service vulnerability in OpenSSL. See patch for installation instructions. Vendor Advisory: http://www.openssl.org/news/secadv_20040317.txt"
What good is a PGP signature when FreeBSD isn't the vendor in question? I wouldn't trust a middle man with my security. What good is a signature on an advisory anyway? The patch alone is signature enough. Read the code yourself and deem it safe or not on your own accord.
As Ken Thompson once put it; "You can't trust code that you did not totally create yourself." So, a signature on code I can't trust, is some sort of benefit? http://www.acm.org/classics/sep95/
"that's just an example, but i think openbsd could gain even more security with improved advisories. or i'm totally wrong?"
You are completely wrong. The OpenBSD security track record speaks for itself.
By Andreas Lundin (217.31.178.176) on
This is all my own personal thoughts, please mod me down if you want to. I am not saying that the advisory from FreeBSD is bad but both OpenBSDs and FreeBSDs advisories cover the same things, basicly.
Lets begin...
The header of the advisory is covered by the errata site, you know if it affects you or not. The only thing that would be of any value here is the 'CVE Name'.
Section I - Background
OpenBSDs errata site provides a link to the online manpage where you can read what the affected subject is all about.
Section II and III
If you read section II(Problem Description) and III(Impact) in the advisory from freebsd you will notice that the one-liner from OpenBSD basicly sais the same thing.
Section IV - Workaround
This can be a good thing to have a little note about when it's possible.
Section V - Solution
The patch and in it you can read how to apply it to your system.
Section VI - Correction Details
Look trough the patch and you will find the same info.
Section VII - References
This could be a nice little thing to have for those who want to know a bit more about the subject.
Comments
By Anonymous Coward (81.169.151.210) on
Comments
By gwyllion (134.58.253.114) on
Comments
By Anonymous Coward (69.158.149.55) on
Last I checked gcc is also GPL licensed and yet the OpenBSD developers seem to use it. I too find the lack of pgp signed security patches and/or alerts a bit odd given the OpenBSD project's focus on security.
By Anonymous Coward (68.124.163.80) on
Why?
"I'm sure Theo or another core developer is able to use GPG. Where's the problem?"
Sure they can. The problem is; there is no reason to do so.
"Just do it."
You do it. Audit the patch, tell the community it is safe, and sign your advisory. Given enough time, people will come to trust what you have to say; especially if you find buggy patches. ;)
By Anonymous Coward (134.58.253.130) on
Is there really no better way?
Comments
By Anonymous Coward (81.182.167.118) on