Hello,
> -----Original Message----- > From: openvas-devel-boun...@wald.intevation.org > [mailto:openvas-devel-boun...@wald.intevation.org] On Behalf > Of Felix Wolfsteller > Sent: Friday, February 05, 2010 6:13 PM > To: openvas-devel@wald.intevation.org > Subject: Re: [Openvas-devel] CR #41 and #42 > > As usual, an uncooked selection of automatic reactions from my side :) > > While the idea of both CRs is great and will result in a > clean up of the NASL NVTs and make them more consistent, I > want to express concern about using the script_tag approach. > > The neatness of the script-tag approach is that in theory > only the NASL scripts themselves have to be updated and there > is no compatibility issues at all. The clients will display > the content of the tags (although currently it will not look > nice, as all tags are cramped together in a single string iirc). > Thats all great and I will probably thus vote +1 ;). Ok, you have voted +1, so I don't need to respond to the below issues :) > > However, in my eyes, the disadvantages are > 1) Tags do not have a clear semantic (e.g. CVSS is a number, > think about sorting). > 2) Typos are hard to find (assume somebody accidentally typed > cvSs), in contrast to a function call like 'meta_info_cvss > (5.0);' where the interpreter (and thus Q&A scripts) would > warn about un-naslness. We already have some kind of QA check once the NVT's are committed to svn to check these documentation related errors. That can be enhanced. script_tag allows you to add any "key" and "value" types whereas in other case, you need to add new functions for each "key". > 3) Many tags will make the nice and relatively new cache > format unreadable again. Again, better than adding new functions for each key that we want to add. > 4) Many tags will probably make the clients view of NVTs look weird. This is the reporting issue. Client should handle. > 5) Start of a "ok, lets do everything with tags"- mentality, > where we need proper solutions. Remember the meta-data > discussions on the devcon. Yes, the goal is to separate the data portion from the script/code. Even in that case, data must be represented in some key/value format. > > > I think its an okay intermediate solution and if you guys can > do the work of touching all these scripts thats a great > effort in the right direction. > > Regarding CR 42: Some nasl- scripts currently do not directly > relate to any security issue (e.g. "General Settings", > "Toolcheck"). These should get an own SEVERITY, too. "None", > or "n/a", "unrelated", "scan-related",...? > Similarly for CR 41, should these get an empty string as > cvss? A "0.0", a "-1"...? I thought "Informational" would take care of such scripts. Adding CVSS is not mandatory, so we need not add 0.0 in such cases. > > Also, it seems that redundant information is delivered in > case both tags are given. The only additional information > gained by "risk_factor" is whether the script is just > "informational", otherwise the level can be deducted from the > cvss score, on client side. Yes, I agree that both Risk factor and CVSS serve the same purpose. I am not sure if there's any real value in adding both. We are just maintaining Risk factor since we have many NVT's that have risk factor. Anybody else thinks the usefulness of keeping both? > If openvas-nasl-tags wouldnt be key-value-pairs I would opt > for the first > community-agreed-on-tag: "informational". > > And I am waiting for the meta-data CR :) I'll hopefully complete this before the next DevCon :) Chandra. _______________________________________________ Openvas-devel mailing list Openvas-devel@wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-devel
