Re: CAN to CVE: changing changelogs?
On Thursday 27 October 2005 23:34, Henrique de Moraes Holschuh wrote: > To me it is a technical matter, as the changelogs are a tool for a > technical job. To me, changelogs are primarily a way of informing the user of changes in a package. Including references to fixed security issues is definitely a part of that. However, when "upstream" policy on a numbering scheme is changed, going back 10 years in changelogs (/me is exaggerating to make a point) and fixing historic references to old entries that were perfectly valid at the time they were written is not a technical matter. I would agree more with the qualification of "revisionist history" made earlier. Of course adding _missing_ references to fixed security issues would be like fixing a minor bug in the changelog. However, that also should not be taken too far: adding entries going back more than half a year (?) seems hardly relevant. pgpOgod08pvGr.pgp Description: PGP signature
Re: CAN to CVE: changing changelogs?
Henrique de Moraes Holschuh wrote: > Found it. From: Martin Schulze <[EMAIL PROTECTED]>, Message-ID: > <[EMAIL PROTECTED]>, and Message-ID: > <[EMAIL PROTECTED]> at > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=282681 "Please add this id to the proper changelog entry with the next upload." That's easily misinterpreted, although I won't try to guess which of us is doing so. One thing that this bug illustrates pretty well that is quite annoying when trying to determine what version of a package actually fixed a security hole, is new upstream releases that are listed in the changelog as fixing a particular CVE, when the hole was actually fixed in a previous debian revision of the old upstream version. That's a case where clarity is very useful in the changelog. (So is proper use of the new version tracking features of the BTS.) -- see shy jo signature.asc Description: Digital signature
Re: CAN to CVE: changing changelogs?
On Thu, 27 Oct 2005, Frans Pop wrote: > On Thursday 27 October 2005 22:30, Henrique de Moraes Holschuh wrote: > > When dealing with Debian matters of a technical nature, yes. When > > dealing with matters outside Debian, or of a non-technical nature, I > > may decide to not take such an instance. And frankly, as long as it is > > a rule of mine, applied to myself, what business is it of yours? > > Problem is that changing historic entries in a changelog is hardly a > technical matter. Hmm, I'd rephrase that to: Is adding detail is the same as changing, when we are talking about changelogs? To me it is a technical matter, as the changelogs are a tool for a technical job. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CAN to CVE: changing changelogs?
On Thu, 27 Oct 2005, Michael Stone wrote: > You know, you could have just not posted in the first place. Posting a > personal opinion about someone else's personal preference and then > ranting about people wasting your time questioning your personal > preferences is just flat out stupid. We all make mistakes. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CAN to CVE: changing changelogs?
On Thu, 27 Oct 2005, Henrique de Moraes Holschuh wrote: > On Thu, 27 Oct 2005, Joey Hess wrote: > > Henrique de Moraes Holschuh wrote: > > > 3. The security team's work is helped by adding the CVE > > > information to the proper changelog entry, to the point that > > > they have requested everyone to do so. This requires editing > > > past changelog entries quite often. > > > > I don't think that the security team has ever requested retoractive > > changing of changelogs for CVE entries. I find it hard to envision a > > THAT will give me a lot of work to track down. This was pre BTS-usertags, Found it. From: Martin Schulze <[EMAIL PROTECTED]>, Message-ID: <[EMAIL PROTECTED]>, and Message-ID: <[EMAIL PROTECTED]> at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=282681 I was out of line on claiming that the security team asked everyone to add CAN/CVE numbers to past changelog entries. There were _two_ requests from Martin Shulze directed to me, while wearing his security team hat, to change past entries in a changelog to add CAN/CVE entries, but that's it. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CAN to CVE: changing changelogs?
On Thursday 27 October 2005 22:30, Henrique de Moraes Holschuh wrote: > When dealing with Debian matters of a technical nature, yes. When > dealing with matters outside Debian, or of a non-technical nature, I > may decide to not take such an instance. And frankly, as long as it is > a rule of mine, applied to myself, what business is it of yours? Problem is that changing historic entries in a changelog is hardly a technical matter. pgpBvZP4gOUW4.pgp Description: PGP signature
Re: CAN to CVE: changing changelogs?
On Thu, Oct 27, 2005 at 06:30:10PM -0200, Henrique de Moraes Holschuh wrote: You are wrong. There ARE technical arguments for that rule: The amount of time I wasted in threads just like the one you are almost goading me into was detracting from the amount of useful Debian work. Maybe this will change someday, and the rule will go away. You know, you could have just not posted in the first place. Posting a personal opinion about someone else's personal preference and then ranting about people wasting your time questioning your personal preferences is just flat out stupid. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CAN to CVE: changing changelogs?
On Thu, 27 Oct 2005, Thomas Bushnell BSG wrote: > > When dealing with Debian matters of a technical nature, yes. When dealing > > with matters outside Debian, or of a non-technical nature, I may decide to > > not take such an instance. And frankly, as long as it is a rule of mine, > > applied to myself, what business is it of yours? > > Um, we're talking about a shared resource here which is designed to > help many people work together. changelogs are not some private > notations of the developer. It is certainly reasonable to expect that > they be maintained by different developers in a consistent way. Ah, ok. You have convinced me that you have a valid reason to discuss editing past changelog entries, which is not what is happening in our last email exchanges in this thread. Or maybe you misinterpreted that I meant the entire *THREAD* about editing past changelog entries was useless? I wrote *subthread* for a reason. Let's go back to the real topic of this thread, outside of this useless subthread, shall we? I even happen to agree with you, a consistent way to deal with changelogs would be nice. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CAN to CVE: changing changelogs?
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: > When dealing with Debian matters of a technical nature, yes. When dealing > with matters outside Debian, or of a non-technical nature, I may decide to > not take such an instance. And frankly, as long as it is a rule of mine, > applied to myself, what business is it of yours? Um, we're talking about a shared resource here which is designed to help many people work together. changelogs are not some private notations of the developer. It is certainly reasonable to expect that they be maintained by different developers in a consistent way. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CAN to CVE: changing changelogs?
On Thu, 27 Oct 2005, Thomas Bushnell BSG wrote: > Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: > > > Parse error: "... that one?" I am sorry, I am not sure I understood what > > you mean. IF I got it right, my reply is simple: I will not change my mind > > about a technical matter backed by technical reasons, because of the beliefs > > of someone else. Give me technical reasons, and I will listen and I could > > be convinced that I am wrong. > > Great. Now you have a rule: > > "I will only listen to technical reasons." When dealing with Debian matters of a technical nature, yes. When dealing with matters outside Debian, or of a non-technical nature, I may decide to not take such an instance. And frankly, as long as it is a rule of mine, applied to myself, what business is it of yours? It was quite clear enough that I was talking about technical reasons since my first post in this subthread. > Where did that rule come from? Was that rule itself backed by > technical reasons? No. I sense an inconsistency. You are wrong. There ARE technical arguments for that rule: The amount of time I wasted in threads just like the one you are almost goading me into was detracting from the amount of useful Debian work. Maybe this will change someday, and the rule will go away. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CAN to CVE: changing changelogs?
On Thu, 27 Oct 2005, Joey Hess wrote: > Henrique de Moraes Holschuh wrote: > > 3. The security team's work is helped by adding the CVE > > information to the proper changelog entry, to the point that > > they have requested everyone to do so. This requires editing > > past changelog entries quite often. > > I don't think that the security team has ever requested retoractive > changing of changelogs for CVE entries. I find it hard to envision a THAT will give me a lot of work to track down. This was pre BTS-usertags, and I am not sure if it was from the regular sec. team or the testing sec. team, and it was a passing comment on a thread. The "requested everyone" might be a bit strong, I suppose, since a post to d-d-a was not made. Well, I will try to hunt it down but google ain't helping much. > Although these days I think you'll more likely see the relevant bug in > the BTS be usertagged with the CVE id before the package is even > released. Once that tag is there, we're tracking the security issue and > the changelog entry will only matter to users and other security > researchers. Good to know. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CAN to CVE: changing changelogs?
Henrique de Moraes Holschuh wrote: > 3. The security team's work is helped by adding the CVE > information to the proper changelog entry, to the point that > they have requested everyone to do so. This requires editing > past changelog entries quite often. I don't think that the security team has ever requested retoractive changing of changelogs for CVE entries. I find it hard to envision a scenario where that would be more useful to them than a note in the next release. I am quite sure that the testing security team has not asked for such retroactive changes, and that we don't need them. Of course we do appreciate it when maintainers put CVE information in changelogs, and we've asked them to do so. Although these days I think you'll more likely see the relevant bug in the BTS be usertagged with the CVE id before the package is even released. Once that tag is there, we're tracking the security issue and the changelog entry will only matter to users and other security researchers. -- see shy jo signature.asc Description: Digital signature
Re: CAN to CVE: changing changelogs?
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: > Parse error: "... that one?" I am sorry, I am not sure I understood what > you mean. IF I got it right, my reply is simple: I will not change my mind > about a technical matter backed by technical reasons, because of the beliefs > of someone else. Give me technical reasons, and I will listen and I could > be convinced that I am wrong. Great. Now you have a rule: "I will only listen to technical reasons." Where did that rule come from? Was that rule itself backed by technical reasons? No. I sense an inconsistency. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CAN to CVE: changing changelogs?
On Thu, 27 Oct 2005, Thomas Bushnell BSG wrote: > Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: > > But at least we know that this subthread can end right here, right now. It > > is useless to discuss beliefs that exist without a technical backing, and I > > won't waste my time with it. > > Do you have a technical backing for your view that it is useless to > discuss beliefs that one? Parse error: "... that one?" I am sorry, I am not sure I understood what you mean. IF I got it right, my reply is simple: I will not change my mind about a technical matter backed by technical reasons, because of the beliefs of someone else. Give me technical reasons, and I will listen and I could be convinced that I am wrong. Therefore, I will not waste my time with any thread where I ask for technical reasons and get an ideologic one as a reply. And I won't waste my time arguing for the sake of arguing, either. As for the technical reasons to update and modify past entries in a changelog, I can name a few without any effort: 1. Fixing typos do not change the message. If it does, it is not a simple typo. Typos can cause a grep for information to fail, thus they are not always harmless. Typos distract me, therefore I fix them on *my* changelogs when I notice them, so that they won't distract me ever again. 2. By properly updating/fixing closes: entries, one can always machine-parse the changelog to locate exactly when a bug was fixed. I can use this to feed the new version-aware BTS with missing versioning information, for example, if I need/want to. Also, by adding the proper closes: entries in the changelog, now I have a link to the BTS entry that is related to that changelog entry. This data is extremely useful when you are hunting the reasons for a particular change down. 3. The security team's work is helped by adding the CVE information to the proper changelog entry, to the point that they have requested everyone to do so. This requires editing past changelog entries quite often. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CAN to CVE: changing changelogs?
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: > But at least we know that this subthread can end right here, right now. It > is useless to discuss beliefs that exist without a technical backing, and I > won't waste my time with it. Do you have a technical backing for your view that it is useless to discuss beliefs that one? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CAN to CVE: changing changelogs?
On Thu, 27 Oct 2005, Horms wrote: > > > I believe that changelogs should never be changed restrospectively. > > > > Why not? Technical reasons only, please. Fixing changelogs so that they > > are more useful in the future is common in Debian. These are slight edits, > > always, not entry suppresion or something like that. Trimming them down is > > also very common on long-standing packages, and something that is needed. > > Usually, the older entries are moved to a separate file to rot there > > out-of-the-way. > > Because I don't believe in revisionist history, thats all. That's an extremely weak argument IMO. I will continue doing what the security team asks and add CVE numbers to the versions that closed security bugs, as well as fixing typos and the like when I notice them on my changelogs. I do not consider this to be revisionist history. But at least we know that this subthread can end right here, right now. It is useless to discuss beliefs that exist without a technical backing, and I won't waste my time with it. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CAN to CVE: changing changelogs?
On Thu, Oct 27, 2005 at 09:47:15AM -0200, Henrique de Moraes Holschuh wrote: > On Thu, 27 Oct 2005, Horms wrote: > > On Wed, Oct 26, 2005 at 11:32:15AM +0200, Thijs Kinkhorst wrote: > > > Hello people, > > > > > > As many of you are probably aware, CVE has changed the naming of their > > > id's: the temporary "CAN-" prefix has been dropped and an id is now > > > always of the form CVE--. More information at the CVE website. > > > > > > I was wondering what to do with changelogs. I think it might make sense > > > to rename CAN-... numbers in old entries to CVE-..., since all entries > > > have been renamed and this aids to the goal: having one unique string to > > > find any vulnerability by. > > > > > > Are there any thoughts on changing changelogs retroactively? Might it > > > even be an idea to add a lintian check for 'old-style' CAN id's? > > > > I believe that changelogs should never be changed restrospectively. > > Why not? Technical reasons only, please. Fixing changelogs so that they > are more useful in the future is common in Debian. These are slight edits, > always, not entry suppresion or something like that. Trimming them down is > also very common on long-standing packages, and something that is needed. > Usually, the older entries are moved to a separate file to rot there > out-of-the-way. Because I don't believe in revisionist history, thats all. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 874-1] New lynx packages fix arbitrary code execution
Christophe Chisogne a écrit : > I guess lynx-ssl is affected too ? Is a lynx-ssl being prepared ? Ok, it's DSA 876-1, solved :) DSA-876-1 lynx-ssl -- buffer overflow http://www.debian.org/security/2005/dsa-876 But I had a problem : I upgraded from Woody to Sarge. Woody had non-US, which Sarge dont have anymore. lynx-ssl/Woody was in non-US, but wasnt remove/replaced by the new lynx/Sarge during upgrade. So I had a system with an old unpatched lynx-ssl and not the current patched lynx (trivially solved with aptitude install lynx). The problem didnt seemed obvious at first, so I share my little experience here. If others have problems with non-US, I found a simple way to list the non-US packages (if grep-dctrl is installed): use grep-status, with a command like that one: # grep-status -F Section non-US -s Package,Version,Status Hope it can help others. Ch. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
unsubscribe
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CAN to CVE: changing changelogs?
On Thu, 27 Oct 2005, Horms wrote: > On Wed, Oct 26, 2005 at 11:32:15AM +0200, Thijs Kinkhorst wrote: > > Hello people, > > > > As many of you are probably aware, CVE has changed the naming of their > > id's: the temporary "CAN-" prefix has been dropped and an id is now > > always of the form CVE--. More information at the CVE website. > > > > I was wondering what to do with changelogs. I think it might make sense > > to rename CAN-... numbers in old entries to CVE-..., since all entries > > have been renamed and this aids to the goal: having one unique string to > > find any vulnerability by. > > > > Are there any thoughts on changing changelogs retroactively? Might it > > even be an idea to add a lintian check for 'old-style' CAN id's? > > I believe that changelogs should never be changed restrospectively. Why not? Technical reasons only, please. Fixing changelogs so that they are more useful in the future is common in Debian. These are slight edits, always, not entry suppresion or something like that. Trimming them down is also very common on long-standing packages, and something that is needed. Usually, the older entries are moved to a separate file to rot there out-of-the-way. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 875-1] New OpenSSL packages fix cryptographic weakness
[EMAIL PROTECTED] (Martin Schulze) wrote: > The following matrix explains which version in which distribution has > this problem corrected. > > oldstable (woody) stable (sarge) unstable (sid) > openssl 0.9.6c-2.woody.8 0.9.7e-3sarge1 0.9.8-3 > openssl 094 0.9.4-6.woody.4 n/a n/a > openssl 095 0.9.5a-6.woody.6n/a n/a > openssl 096 n/a 0.9.6m-1sarge1n/a > openssl 097 n/an/a0.9.7g-5 This is confusing - openssl 097 is marked as "n/a" for sarge, while in fact the openssl package has version 0.9.7. It is only logical if you know the names of the source packages, but you shouldn't expect that From every one reading that advisory. > Debian GNU/Linux 3.0 alias woody > Furthermore, it would be great if these mails would state somewhere in the actual text for which distributions an update is already available (and possibly for which arches). I read the mail cursory, decided that I did not need to know the details, just upgrade, and was surprised that aptitude had nothing to upgrade. I had to read the mail again, scrolling along the list of woody packages, to learn that there is nothing but woody packages. Thanks for considering, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer pgpdzRSPNxVcZ.pgp Description: PGP signature
Re: [SECURITY] [DSA 874-1] New lynx packages fix arbitrary code execution
Martin Schulze a écrit : > Debian Security Advisory DSA 874-1 [EMAIL PROTECTED] > (...) > Package: lynx > (...) > For the stable distribution (sarge) this problem has been fixed in > version 2.8.5-2sarge1. I guess lynx-ssl is affected too ? Is a lynx-ssl being prepared ? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
