CAN to CVE: changing changelogs?

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

CAN to CVE: changing changelogs?

Thijs Kinkhorst
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-yyyy-nnnn. 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?


regards,
Thijs Kinkhorst

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CAN to CVE: changing changelogs?

Moritz Mühlenhoff-2
In gmane.linux.debian.devel.security, you wrote:

> 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-yyyy-nnnn. 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?

You could change them retroactively (with a little note that you did so),
but it's not strictly necessary, as MITRE will continue to provide referrals
from CAN-based entries to CVE-based entries.

Cheers,
        Moritz


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: CAN to CVE: changing changelogs?

Michael Stone-2
In reply to this post by Thijs Kinkhorst
On Wed, Oct 26, 2005 at 11:32:15AM +0200, Thijs Kinkhorst wrote:
>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.

No. People aren't that stupid, I'm sure they can figure it out.

Mike Stone


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: CAN to CVE: changing changelogs?

Thijs Kinkhorst
In reply to this post by Moritz Mühlenhoff-2
On Wed, 2005-10-26 at 12:36 +0200, Moritz Muehlenhoff wrote:
> > 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?
>
> You could change them retroactively (with a little note that you did so),
> but it's not strictly necessary, as MITRE will continue to provide referrals
> from CAN-based entries to CVE-based entries.

Wouldn't one of the goals of the change to just one name instead of two
per issue be to facilitate things like googling, grepping and other
searching on CVE id's? Then it would make sense to unify the names as
widely as possibe.


Thijs

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CAN to CVE: changing changelogs?

Bernd Eckenfels
In article <[hidden email]> you wrote:
> Wouldn't one of the goals of the change to just one name instead of two
> per issue be to facilitate things like googling, grepping and other
> searching on CVE id's? Then it would make sense to unify the names as
> widely as possibe.

Those issues are old, and the work to look up the new ids and change them is
quite big.

Gruss
Bernd


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: CAN to CVE: changing changelogs?

Florian Weimer
In reply to this post by Thijs Kinkhorst
* Thijs Kinkhorst:

>> You could change them retroactively (with a little note that you did so),
>> but it's not strictly necessary, as MITRE will continue to provide referrals
>> from CAN-based entries to CVE-based entries.
>
> Wouldn't one of the goals of the change to just one name instead of two
> per issue be to facilitate things like googling, grepping and other
> searching on CVE id's?

It's Google's job to improve their search engine, not ours.

> Then it would make sense to unify the names as widely as possibe.

You can't be sure that everybody makes the change, so you still have
to search for both variants anyway.  I don't think it makes sense to
apply the conversion to anything which is not som sort of CVE-based
database.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: CAN to CVE: changing changelogs?

Joey Hess
In reply to this post by Thijs Kinkhorst
Thijs Kinkhorst wrote:
> Wouldn't one of the goals of the change to just one name instead of two
> per issue be to facilitate things like googling, grepping and other
> searching on CVE id's? Then it would make sense to unify the names as
> widely as possibe.

It's not worth worrying about doing, unless you previously worried about
doing it on a per-CAN basis, as CANs were one at a time promoted to CVEs.

--
see shy jo

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CAN to CVE: changing changelogs?

Simon Horman-2
In reply to this post by Thijs Kinkhorst
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-yyyy-nnnn. 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.

--
Horms


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: CAN to CVE: changing changelogs?

Henrique de Moraes Holschuh
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-yyyy-nnnn. 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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: CAN to CVE: changing changelogs?

Simon Horman-2
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-yyyy-nnnn. 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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: CAN to CVE: changing changelogs?

Henrique de Moraes Holschuh
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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: CAN to CVE: changing changelogs?

Thomas Bushnell, BSG-2
Henrique de Moraes Holschuh <[hidden email]> 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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: CAN to CVE: changing changelogs?

Henrique de Moraes Holschuh
On Thu, 27 Oct 2005, Thomas Bushnell BSG wrote:
> Henrique de Moraes Holschuh <[hidden email]> 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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: CAN to CVE: changing changelogs?

Thomas Bushnell, BSG-2
Henrique de Moraes Holschuh <[hidden email]> 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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: CAN to CVE: changing changelogs?

Joey Hess
In reply to this post by Henrique de Moraes Holschuh
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 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CAN to CVE: changing changelogs?

Henrique de Moraes Holschuh
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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: CAN to CVE: changing changelogs?

Henrique de Moraes Holschuh
In reply to this post by Thomas Bushnell, BSG-2
On Thu, 27 Oct 2005, Thomas Bushnell BSG wrote:

> Henrique de Moraes Holschuh <[hidden email]> 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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: CAN to CVE: changing changelogs?

Thomas Bushnell, BSG-2
Henrique de Moraes Holschuh <[hidden email]> 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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: CAN to CVE: changing changelogs?

Henrique de Moraes Holschuh
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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: CAN to CVE: changing changelogs?

Michael Stone-2
In reply to this post by Henrique de Moraes Holschuh
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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

12