According to Anil’s blogpost the speed of update deployment is key these days, so to better understand how useful the advisories in its current form are it’d be useful to know:
Do you use an OCaml application in production (including distributing it to your users)?
How much time do you usually need from receiving the security advisory to deploying a fixed version?
Would a pre-notification of security issues be useful to you to better prepare for updating? (e.g. some projects like OpenSSL announce ahead of time when the next security release is scheduled for high impact issues)
Thanks to the security team for the work you have been doing so far! I’ve found the reports to be really well-structured, which allows us to quickly determine if we are vulnerable (especially when combined with ‘opam audit’). ‘affected_bindings’ are a great help in particular, when it’s available.
I am one of the maintainers of the Xapi Project ( Xapi Project · GitHub ), an OCaml control plane for the Xen hypervisor that’s part of Citrix and XCP-ng hypervisor products.
I’m not sure an open pre-notification (just a notice of an upcoming security fix without any patches etc.) would be of much help - and given Anil’s arguments could easily provide additional time for attackers to scan recent activity of security team members (which repositories have been accidentally forked in public, which packages have had sudden activity bursts etc.) to find the bug ahead of time.
OpenSSL also pre-discloses high-severity issues to some organizations ahead of time (with details and patches). Is this an option that the security team is open to? I understand it will be much more difficult to determine list membership in our case when compared to OpenSSL.
We have not been vulnerable to any issues so far, so I can’t be certain as to the fix rollout timeline, but while we could package a fix on the same day, tests will take more time. If we were vulnerable to yesterday’s (Thursday the 10th of September) issues, for example, we would not be able to release a fix this week. Could I suggest a simple measure of coordinating issue disclosures to be on Tuesdays (as is standard practice with “Patch Tuesdays”)?
Thanks for your reply. Indeed a pre-disclosure mailing list is an interesting idea, but the question remains who’ll be on that list? Maybe an easy solution would be “all OCSF sponsors are invited to join” - but then this pre-release list is the OCaml Security Team.
About patch Tuesdays. We’ll try to stick to these. Sometimes we’re not in control of publishing the fixed packages, but just the advisories. So, if package Y is released on a Wednesday, should we wait until next Tuesday with the advisory?
Perhaps counter-intuitively, a practice I have found very useful to my own triaging of vulnerabilities in dependencies is a “no need to update if…” section.
Obviously in an ideal world everyone would update their insecure dependencies as promptly as possible, but it is worth recognizing that there is a lot of alarm fatigue for downstream developers. By stating something like “There is no need to update if you do not call function xyz with abc argument”, it makes it much easier to pay attention to the situations in which I do need to take action, and I find this negative phrasing easier to follow than the examples of exploits that often accompany CVEs.
IIUC disclosure here referred to either the advisory, or the public patch (whichever is first). From a downstream distribution’s point of view delaying just the advisory wouldn’t help, because attackers would then have a head start (well it depends how much additional information the advisory has that cannot be inferred from the patch and surrounding code alone).
