Re: CVE ID语法投票,结果和下一步

我认为任意长度的问题也是一个关心解析CVE的从一个电子邮件或网页,他们可能只是内联文本,没有null-terminations。安迪在2013年4月26日上午9时10分许,展台,哈罗德写道:> - - - - - - - - - - - >从原始信息:马尼恩艺术(mailto: amanion@cert.org]>发送:星期五,2013年4月26日凌晨四点半>:展位,哈罗德> Cc: cve-editorial-board-list >主题:Re: CVE ID语法投票,结果和下一步> > 2013-04-25 04:17,展台,哈罗德写道:> > > > *你渴望一个静态CVE ID长度?> > > > > >是的,指定的最大长度是更容易编写解析和> > >验证逻辑,在一天结束的时候每个人都必须> > >决定某种截止。> > >我不表达偏好,以null结尾的字符串,但难以解析吗?“CVE -”或“CVE-YYYY——”或“CVE”> >开始的字符串,读到最后,你现在有你的身份证。> > (HB)不,不难以解析,但你真的想有一个输入到您的应用程序中,有人可以给你一个无限长度字符串?每个人都需要确定一些最大长度,他们愿意除了任何给定的输入或承担的后果当有人利用这样的事实你不检查你的输入。> > > > - 0的评论亚当的建议吗?> > > > > >是模糊的数字十整除,例如想象如果> > > CVE今天落后而不是前导零,我们有以下数量:> > > > > > 1000 > > > > > >这是一个1和三个0 ?10有两个0 ?> > > 100年与一个后补零?或1000年不落后于0 ? > >> Seems pretty clear it's 1000 (one thousand) with no trailing zeros, positional notation and all, if the ID is a number leading zeros are decoration only, >trailing zeros matter. > > [HB] Absent some other clarification, no, it's not clear what it is if all numbers have zeros added to the end of the string to make them the same number of digits. And given that this suggestion has been withdrawn I'm not sure it's worth discussing any more anyway. > >> And, treat the ID as a string! Even a string that you can safely expect to be digits, like this regex I looked up on stackoverflow: ^[0-9]{1,6}$ > > [HB] I think one should always perform input validation on strings if the input format is known a priori. At the risk of going down a rabbit hole, while I think identifiers for machine consumption should largely be treated as opaque strings with no semantic meaning embedded within them, there is often embedded meaning in identifiers that are used by humans. Dewey decimal system, phone numbers, VINs, and credit card numbers are examples where an identifier can be largely be treated as an opaque string, but embedded in the identifier there is some meaning (limited) that can be derived if one wants to process that meaning. There are reasons why they have this meaning in them and I think it would be a mistake to not be aware of why they ended up the way they are. > > >> If IDs are variable length strings and there are no special formatting rules, then CVE-1999-00100 and CVE-1999-0100 are different... > > [HB] This would be horrible. Based on this example, I am amending my previous statement that I have no strong opinions regarding padding. I think the padding rules must be consistent. If the two example IDs Art provides above are to be treated differently, that would be horribly confusing and lead to all kinds of errors. And to echo Andy and Steve's comments, regardless of eventual format rules, I think tools should allow human users as much flexibility as possible when they attempt to use a CVE. > >> I guess there's a desire to keep the ID an integer, issued more or less sequentially? This isn't really related to the syntax >> change, unless treating the ID as a string affects the leading/trailing zeros > > [HB] I think it matters that we all agree on a format for the identifier. How the identifiers are assigned to vulnerabilities and in what manner can largely be a separate question as long the agreed upon format does not hinder alternate models of assignment in the future. And that last point I think is where there is likely some disagreement. > > >> - Art