Re: Possibility of LTS fix for Samba?
On Thu, 2023-07-20 at 14:13 +0100, Ronny Adsetts wrote: > I think upgrading our Samba servers to Bullseye and then Samba from > backports (or Michael's repo) is the approach I'll take. Is upgrading to Debian bookworm after that not possible for you? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Any Chance of a Live Kernel Update?
On Wed, 2023-02-22 at 12:13 +0100, Ola Lundqvist wrote: > Unfortunately not the correct mailing list. > This is the mailinglist for security updates of buster. The request for applying Linux kernel security fixes without reboot is even more useful for Debian oldstable/stable, which do not recieve major version upgrades for the Linux kernel, only minor ones, which presumably are possible to turn into Linux kernel livepatch modules. AFAIK the only available Linux kernel livepatch services are from RedHat, SUSE, Ubuntu etc and all of them require paid subscriptions. I expect the Freexian sponsors would welcome such a service for Debian and it seems like a good idea even if it was to be a paid subscription. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Upgrades from Stretch to Bullseye and from Buster to Bookworm broken
On Mon, 2022-10-24 at 09:54 +0200, Anton Gladky wrote: > thanks for the information. AFAIK skipping releases is not supported. > You have to go through all releases step-by-step. Thats correct, although some folks want Debian to not drop things that help skip upgrades wherever possible. https://diziet.dreamwidth.org/13087.html https://diziet.dreamwidth.org/11840.html -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Vulnerability in pcs or is it in more generic code?
On Fri, 2022-09-09 at 22:41 +0200, Ola Lundqvist wrote: > I see that I was not clear what I meant with "in general" :-) Woops, sorry for the noise :) > Here I found how the generic source code looks like: > https://rubydoc.info/gems/thin/1.3.1/Thin%2FBackends%2FUnixServer:connect > > You can see the umask(0) there. > > That is what I think is insecure, not pcs itself. Agreed. > But I think Thin::Backends::UnixServer#connect is still insecure. It looks like the issue was introduced in this pull request: https://github.com/macournoyer/thin/pull/28 It sounds like unicorn might have the same issue as thin. Looking at the unicorn code, it sets the default umask to 0 when the umask option is not set, so not quite as bad but still. The justification for the default umask of 0 in unicorn is: # Typically UNIX domain sockets are created with more liberal # file permissions than the rest of the application. By default, # we create UNIX domain sockets to be readable and writable by # all local users to give them the same accessibility as # locally-bound TCP listeners. So the choice of umask 0 is deliberate in unicorn and the thin folks copied that choice and dropped the possibility of overriding it, since they did't have an options argument for the function. Since UNIX domain sockets are often used for situations that are not like localhost TCP sockets, that was probably the wrong choice, but the unicorn/thin folks are likely from the web developer community, which is mostly focused on HTTP and TCP and often use localhost for development, so it was the right choice within their bubble. I feel like the APIs of both thin and unicorn need redesigning so that the choice of umask to use must be made by the caller. Then the web developer community can use 0 and others will choose a safe value. Really the web developer community shouldn't use 0 either but I expect that convincing them of that might not be possible. I'm not sure how palatable the API change will be to thin/unicorn. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Vulnerability in pcs or is it in more generic code?
On Mon, 2022-09-05 at 21:38 +0200, Ola Lundqvist wrote: > I agree that it is good to fix the pcs package, but shouldn't we fix > the default umask in general? > I would argue that the default umask is insecure. bookworm login sets new user home directories to secure permissions: $ grep -E 'HOME_MODE\s*[0-9]' /etc/login.defs #HOME_MODE 0700 This somewhat mitigates, but not completely, the umask being insecure: $ grep -E 'UMASK\s*[0-9]' /etc/login.defs UMASK022 I can't find any bugs open about changing the default umask, but it was mentioned in replies to the recent adduser thread: https://lists.debian.org/msgid-search/yiejaly0ny0+0...@torres.zugschlus.de -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Tracking related source packages
On Fri, Feb 26, 2021 at 3:35 PM Markus Koschany wrote: > How can we keep the [embedded copies] list up-to-date? Considering that the copies can be added, removed or made irrelevant in each upload of each package, I think this would be a very hard problem. The simplest solution would be to change the triage procedure to include searching for other copies of the affected code via apt-file, codesearch.d.n and sources.d.o ctags, this would increase the triage workload a lot though. Another option would be to automate the process of searching for code copies and provide a service for listing potential code copies. The SourcererCC project seems like something that could potentially be useful for this. This would have the downside of surfacing irrelevant copies that aren't used during the build process, but perhaps that would still be useful to encourage maintainers to ask upstreams to drop the copies. https://wiki.debian.org/EmbeddedCopies https://github.com/Mondego/SourcererCC -- bye, pabs https://wiki.debian.org/PaulWise
Re: Tracking related source packages
On Thu, Feb 25, 2021 at 10:41 PM Ola Lundqvist wrote: > Finding embedded code copies is harder. There are some useful strategies for that listed on the wiki: https://wiki.debian.org/EmbeddedCopies Probably `apt-file search -I dsc` and the various code searching services (sources.d.o hashes/ctags, codesearch.d.o regexes etc) are the most useful ways of finding them. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Support for insecure applications
On Fri, 2021-02-12 at 14:40 +0100, Ola Lundqvist wrote: > The discussion is more or less whether packages should be allowed in > Debian in the first place. This should be discussed on some general > mailinglist, like debian-devel or debian-project. LTS cannot put > restrictions on what should enter Debian in general. Agreed, I encourage the team to start that discussion. > But most software can actually be quite badly written and this is not > a problem from a security standpoint. In an increasingly networked world it is hard to have poorly written software that doesn't interact with untrusted data at some point. > If the user use insecure software in the right way it can work just > fine. For example if you are using a text editor to write your own > software that editor can have all sort of software problems without > causing a security issue. In a world where people are cloning git repositories from strangers and loading the code locally, poorly written text editors can theoretically become security liabilities. > In many cases it is better to have some software that fit your > purpose even though they are not the best from a security point of > view. Agreed. > I maintained Vnc (version 3) for many years. Vnc (3) was not in any > way secure, at least it was not in the beginning. However with decent > firewalls around your network this is not really an issue. We need more sandboxing and other ways to use poorly written software that avoid their potential for security liabilities. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Support for insecure applications
On Fri, Feb 12, 2021 at 11:21 AM Sylvain Beucler wrote: > Pushing your point, we'd need to consider all software insecure by > default, perform regular code audits on the full Debian archive, which > would be very costly, and blocking packages from reaching testing, which > would introduce another bottleneck there. The right place to be blocking poorly written software is before they enter the archive. I would like to suggest that folks interested in improving the security of incoming packages work on that. The first way to do so would be to influence uploading DDs and DMs to do at good auditing before adding new packages and minimal auditing on new package versions. Myself and Jakub Wilk worked on check-all-the-things, which makes it easier for devs to run static analysis and other tools over directory trees. Another option would be to have central infrastructure running the relevant tools, in the past there were DACA and Debile. Right now we have DACA2 from cppcheck upstream, but that just checks our upstream tarballs, ignoring our patches. We also have tarzeau's static analysis report, which ad-hoc runs a bunch of different tools over the archive. None of the static analysis tool outputs have ever been presented on the PTS, DPT, DDPO or anywhere else maintainers regularly look though. https://github.com/collab-qa/check-all-the-things/ https://wiki.debian.org/qa.debian.org The second way would be to start auditing new and existing packages where the maintainer is requesting a sponsor. Most sponsorship requests arrive on debian-mentors in the form of RFS mails, but a lot of sponsorship is handled via teams. This could help build a culture of doing auditing, by ensuring that new folks at least know what tools are out there. I've been doing a bit of this by running check-all-the-things and poking people towards looking at the results in response to RFS mails. -- bye, pabs https://wiki.debian.org/PaulWise
Re: golang-go.crypto / CVE-2019-11841
On Mon, Nov 9, 2020 at 10:33 PM Brian May wrote: > What is this "Built-Using" header? It documents which source package versions need to be shipped to ensure license compliance. https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using Please note that golang folks were/are using it in a more general way than the use it was intended for. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Wheezy ELTS?
On Tue, Apr 16, 2019 at 10:20 AM PICCORO McKAY Lenz wrote: > was removed or not? are stil ELTS? The timeline says that eLTS support ended on 31st May 2019. https://wiki.debian.org/LTS/Extended -- bye, pabs https://wiki.debian.org/PaulWise
Re: [SECURITY] [DLA 1602-1] nsis security update
On Sat, Dec 1, 2018 at 6:35 AM Thorsten Alteholz wrote: > Package: nsis > Version: 2.46-10+deb8u1 > CVE ID : CVE-2015-9267 CVE-2015-9268 > > Among others, Andre Heinicke from gpg4win.org found several issues of > nsis, a tool for creating quick and user friendly installers for > Microsoft Windows operating systems. I note that the Debian package win32-loader (and the corresponding .exe version) likely need to be rebuilt using the fixed version of NSIS. I suggest that a note of this be made somewhere in the security tracker repository so that any future fixes also get corresponding win32-loader rebuilds. There are no other reverse build-deps at this time but the note should mention that most likely all reverse build-deps need to be rebuilt, since nsis is a toolchainish package. http://ftp.debian.org/debian/tools/win32-loader/oldstable/ -- bye, pabs https://wiki.debian.org/PaulWise
Re: Confusing our users - who is supporting LTS?
On Wed, Oct 24, 2018 at 4:15 AM Sean Whitton wrote: > > On Tue 23 Oct 2018 at 05:06PM +0200, Markus Koschany wrote: > > > > In short: Make it very clear if you want to provide long-term support > > for your project. Talk to the LTS team in case you need help. Nobody is > > forced to do anything. > > This is a good idea, but ISTM the assumption should be that the > subproject does not participate unless it explicitly says that it does. This thread started because users have the opposite assumption. So I think it would be better to be explicit about support teams and timelines. -- bye, pabs https://wiki.debian.org/PaulWise
Re: twitter-bootstrap / CVE-2018-14040 / CVE-2018-14041 / CVE-2018-14042
On Thu, 2018-08-09 at 16:57 +1000, Brian May wrote: > I could still ping the host, so probably not a routing problem. Next time try connecting to port 80/443 on the IP address without sending any data. That would eliminate a HTTP-layer issue. > Looks like I can connect today however, so maybe transient blackhole? Or temporary overload. If it happens again, the curl output of the IP address will tell you which StackPath datacenter you connected to and it does not go to the security-tracker hostname so it should return results immediately and might be blacklist independent. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: twitter-bootstrap / CVE-2018-14040 / CVE-2018-14041 / CVE-2018-14042
On Wed, Aug 8, 2018 at 3:35 PM, Brian May wrote: > Sidenote: Curiously I cannot connect to > https://security-tracker.debian.org/ today from this machine on this > network... Connections always time out. Probably something weird with my > network, however other webpages appear to be fine. If I ssh into my home > computer and use w3m it works fine. The site has been moved to MaxCDN so it is likely that they have blackholed your network or there is some sort of routing issue between you and their local node. -- bye, pabs https://wiki.debian.org/PaulWise
Re: CVE-2018-1050 and CVE-2018-1057 for samba
On Wed, Mar 14, 2018 at 4:42 PM, Mathieu Parent wrote: > See the attached patch for CVE-2018-1050 on samba 3.6. CVE-2018-10507 > is on the AD DC code which is not part of samba 3.6. A beta of samba 4 is also in wheezy: https://packages.debian.org/source/wheezy/samba4 -- bye, pabs https://wiki.debian.org/PaulWise
Re: pulling in other vulnerability databases
On Thu, 2018-01-25 at 11:05 -0500, Antoine Beaupré wrote: > I'm not sure what to say to nodesecurity.io folks I've already contacted them multiple times in 2014 and once in 2016, about incorporating CVEs into their workflow. The responses were positive but didn't result in much change, except when the issues were sent to oss-sec or Mitre by the Debian security team or myself or others. Most of their recent advisories have CVEs but some don't. I'm guessing the researchers who discovered the issues are getting CVEs. I think the best outcome would be if NodeSecurity could become a CNA so they could issue CVEs immediately with each advisory they send out. https://marc.info/?i=1399944995.3095.25.camel@chianamo https://marc.info/?i=1411952951.6106.20.ca...@bonedaddy.net https://marc.info/?l=oss-security=139757263925026=2 http://www.openwall.com/lists/oss-security/2016/02/20/2 http://www.openwall.com/lists/oss-security/2016/01/12/2 > pabs, did you have any issues in mind that were problematic here > specifically? Here is one example culled from my email archive: http://bugs.debian.org/862712 https://nodesecurity.io/advisories/338 https://security-tracker.debian.org/tracker/862712 It didn't end up getting added to the security tracker, didn't get a CVE and only got fixed in Debian after I filed a bug about it. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: pulling in other vulnerability databases
On Thu, Jan 25, 2018 at 1:12 AM, Antoine Beaupré wrote: > Okay, so this is a broader, recurring problem we have with the security > tracker right now... From my perspective, I've always and only used CVEs > as unique identifiers for vulnerabilities in my work in the security > tracker. When that was not possible, say because a CVE wasn't issued > yet, CVE-- templates were used, which leads to ugly TMP-FOO > markers in the web interface. That is how things are supposed to work indeed. > Are you saying there are ways, right now, in the security tracker, to > use non-CVE identifiers as unique markers in a meaningful way? Not AFAIK. I think that having non-CVE identifiers on hand is a useful but secondary goal. Achieving the primary goal also makes it easier to achieve this too. I'm mainly pointing out we need better automated ingestion of vulnerability data for multiple reasons: Mitre is *very* slow at unrestricting CVE information after a project has published advisories, just look in CVE/list for things that are still RESERVED but we have data for. There are more vulnerability databases than just CVEs and this problem is not going to go away. Some of these may (partially) overlap with the CVE database. The manual ingestion of vulnerability information into the security tracker currently falls mainly on just one person (carnil). Having just one person do all of that work isn't fair on them and does not scale. If we automate more ingestion then there will be less latency and he will have less work to do and be able to focus more on other things like vulnerability feeds that aren't automatable (like mailing lists). > we discussed using BTS bug numbers in the past, but right now > those are, as far as I know, bound to entries in data/CVE/list only. Correct. > Where should we start to implement the above? Any pointers to where a > Python dev might look in the security-tracker source to actually work on > this? It seems this would also affect the DSA/DLA release process - i > think it *is* possible to actually release a CVE-less DSA right now, but > I wonder if the process would stall in other places... First we should decide if we want non-CVE identifiers and define how we want to represent non-CVE identifiers in data/CVE/list. I would go for yes and something like this: CVE-2017-17565 (An issue was discovered in Xen through ...) ... ID: XSA-251 Next the database would need an additional identifier mapping table. The CVE page could then also list XSA-251 in the Name field, linked to the canonical location for XSAs. The search field could be used to lookup XSAs and redirect to the right CVE page, just like we do for BTS entries. After that I'm not sure, but I think I would look at how the 'automatic updates' commits happen and then extend that process to include other types of data feeds than just the CVE one. I started a list of possible feeds in check-external/sources.ini I think the GSoC or Outreachy would be an ideal way to achieve this and wrote a proposal a couple of years ago, but couldn't find anyone interested in mentoring it. ISTR last time I brought up this idea it was dismissed as a bad idea. https://wiki.debian.org/SummerOfCode2015/ProjectProposals/SecurityTrackerCheckExternal > And are we admitting here that we should just give up on the CVE process > in those cases? Or should we make an effort (say like we do in reporting > bugs against packages in teh BTS) to actively seek CVE identifiers for > vulnerabilities that lack them, like I did for the jquery issues? I don't think it is a good idea to give up on the CVE process and I think doing so would be a violation of the Debian Social Contract. In my opinion it would be a good idea (modulo workload issues) to seek CVE identifiers for vulnerabilities reported in all vulnerability databases, just like is done for the BTS (tag=security is kind of a vuln db) and other locations. > Sorry to bring so many questions and so few answers, but I figured it is > useful to actually scope out the problem better before starting an > implementation. :) Quite. -- bye, pabs https://wiki.debian.org/PaulWise
Re: jquery CVEs: no-dsa or unsupported? + snyk.io
On Fri, Jan 19, 2018 at 11:52 PM, Antoine Beaupré wrote: > I have found that Snyk had issues in its database that weren't in Mitre: > > https://snyk.io/vuln/npm:jquery I note that nodesecurity also has some CVE-less issues: https://nodesecurity.io/advisories?search=jquery > Finally, I wanted to bring Snyk.io to the teams' attention. I'm a little > disturbed by that new service - I feel there's significant overlap > between their vulnerability reporting process and Mitre's DWF/DNA > process, even down to using Google forms to welcome submissions, in the > case of DWF (!!). The Snyk (closed) database tracks vulnerabilities in > web apps, mostly, covering the following languages: Golang, Java > (maven), Javascript (npm), .NET (nuget), PHP (composer), Python (pip), > and Ruby (rubygems). I haven't done a formal study, but a quick glance > at the latest issues show that only a small fraction of the issues > reported there have CVE IDs at all. > > This connects with the question of how to track issues without CVEs. In > general, that is a problem we have in the security tracker because it's > so bound to CVE identifiers. But this is a new problem as well: by > opening a new process for submitting vulnerabilities, this system > potentially bypasses the CVE system altogether, using a > commercial/proprietary backend. I am worried about the impact this will > have on our triaging efforts and wonder where we should go from here. > > Food for thought? I would guess there are a lot of different vuln databases out there: Competition for Mitre & CVEs (Snyk) Language communities (NodeSecurity) OS vendors (RH/SUSE) Upstream projects (Xen, Linux etc) Security community (oss-sec, fulldisclosure, conferences etc) Each of them have their own identifiers and possibly also link to CVEs. I'd suggest we need (semi-)automated ingestion of all of the above, like we currently have for CVEs. -- bye, pabs https://wiki.debian.org/PaulWise
Re: apt sources.list for wheezy-to-jessie distro upgrade
On Mon, Nov 27, 2017 at 7:43 PM, Adam Weremczuk wrote: > deb http://httpredir.debian.org/debian/ wheezy main contrib non-free > deb-src http://httpredir.debian.org/debian/ wheezy main contrib non-free You can also replace httpredir.d.o with deb.d.o, httpredir.d.o is dead and now redirects to deb.d.o. -- bye, pabs https://wiki.debian.org/PaulWise
Re: should ca-certificates certdata.txt synchronize across all suites?
On Fri, Jul 7, 2017 at 2:01 AM, Antoine Beaupré wrote: > For what it's worth, my opinion is that we should attempt to synchronize > certdata.txt (and blacklist.txt, for that matter) across all suites (but > not other changes to the packaging). This would remove another decision > point in our infrastructure and ensure harmonious X509 processing across > suites. I would like to see that happen too. -- bye, pabs https://wiki.debian.org/PaulWise
Re: unattended upgrades don't work in wheezy
On Tue, Jul 4, 2017 at 10:02 PM, Matus UHLAR wrote: > I just found out that the unattended-upgrades package in wheezy does not > upgrade packages although configured to do it. I note that this same situation will apply to jessie when it becomes oldoldstable. I haven't tested the default stretch sources.list and u-u configuration. -- bye, pabs https://wiki.debian.org/PaulWise
Re: heads-up: stretch release and changes to security-tracker
On Mon, Jun 12, 2017 at 3:37 AM, Salvatore Bonaccorso wrote: > I'm attaching the *preliminary* set of changes which I plan to > activate once stretch is released. Wow, there really is a horribly large amount of hard-coding of things that should be fetched from the archive instead. I've added a reference to your mail here: https://wiki.debian.org/SuitesAndReposExtension#secure-testing -- bye, pabs https://wiki.debian.org/PaulWise
Re: [Pkg-puppet-devel] Wheezy update of puppet?
On Wed, May 24, 2017 at 6:24 PM, Paul Wise wrote: > In Python/Perl YAML libraries there are ways to safely load YAML > files, does Ruby not have the same possibilities? After a bit of searching, I wonder if copying the ruby-safe-yaml package from wheezy-backports to wheezy and then patching puppet to use that might be a good solution. -- bye, pabs https://wiki.debian.org/PaulWise
Re: [Pkg-puppet-devel] Wheezy update of puppet?
On Wed, May 24, 2017 at 5:51 PM, Apollon Oikonomopoulos wrote: > So, from my understanding the version in Wheezy cannot be fixed: the 2.7 > agents only use YAML to send out facts and upstream's fix is to simply > not accept anything other than PSON. Whitelisting YAML defeats the > purpose, as it's YAML's deserialization of untrusted data that leads to > remote code execution. In Python/Perl YAML libraries there are ways to safely load YAML files, does Ruby not have the same possibilities? -- bye, pabs https://wiki.debian.org/PaulWise
Re: fixing links for DLAs in the security tracker
On Wed, Mar 29, 2017 at 12:28 PM, Salvatore Bonaccorso wrote: > See as well https://bugs.debian.org/761945 (and respective clones for > debian-). Committed a patch for this, carnil deployed it. One downside to this is that committing DLAs to the Debian website hasn't happened since 2016 DLA-445-2: https://security-tracker.debian.org/tracker/DLA-445-2 https://www.debian.org/security/2016/dla-445 https://security-tracker.debian.org/tracker/DLA-446-1 https://www.debian.org/security/2016/dla-446 (404) -- bye, pabs https://wiki.debian.org/PaulWise
Re: Wheezy update of ca-certificates?
On Tue, Mar 28, 2017 at 8:12 AM, Michael Shuler wrote: > I need to fix up the jessie PU I have filed (and update to 2.11), and > I'll do a wheezy PU at the same time. Thanks! Debian wheezy is no longer managed by the release team, so you will need to do an LTS upload instead: https://wiki.debian.org/LTS/Development -- bye, pabs https://wiki.debian.org/PaulWise
Wheezy update of ca-certificates?
Hi all, I note that there have been some CA removals and additions that would be nice to have in wheezy, in particular the ISRG Root for LE, thoughts? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: testing and review requested for Wheezy update of apache2
On Tue, Feb 21, 2017 at 4:27 AM, Antoine Beaupré wrote: > security@lists.d.o is not a list, as far as i know. there's > debian-security@lists.d.o, but I never posted there... or did you mean > t...@security.debian.org? secur...@lists.debian.org goes to root (DSA) and listmaster AFAICT. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Wheezy update of tre?
On Thu, Oct 20, 2016 at 9:59 PM, Santiago Vila wrote: > Should this not start in unstable with a bug report? This is what the stable security team usually do, because they know that if they don't they will eventually have to do the work themselves. They also do NMUs in unstable in some cases. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Please remove non-lts architectures from wheezy-security
On Wed, May 4, 2016 at 12:23 AM, Tom Turelinckx wrote: > Jessie is not available for sparc. If you are actually using sparc I would recommend you look at migrating to and assisting the sparc64 porting efforts. Or reviving sparc if you need 32-bit SPARC. Or switch to another architecture. https://wiki.debian.org/Sparc64 https://lists.debian.org/debian-sparc/ > There is no wheezy directory in http://archive.debian.org/debian/dists/, nor > in http://archive.debian.org/debian-security/dists/. ... > Have these packages been archived somewhere? What is the recommended > sources.list entry to access them? Until the non-LTS wheezy architectures are properly archived, you can use the Debian wayback machine with a date before the LTS started. http://snapshot.debian.org/ Also keep in mind that you are going to have to recompile every LTS update from source for sparc or not get security updates. -- bye, pabs https://wiki.debian.org/PaulWise
Re: tracking security issues without CVEs
On Mon, Mar 28, 2016 at 10:34 PM, Andrew Deck wrote: > On a related note, does anyone know what happened to OSF and the OSVDB? > There still seem to be blog updates, but I remember OSVDB having a web > UI, and the OSF website seems to be down. They have officially closed the OSVDB site: https://blog.osvdb.org/2016/04/05/osvdb-fin/ -- bye, pabs https://wiki.debian.org/PaulWise
Re: tracking security issues without CVEs
On Tue, Mar 22, 2016 at 10:06 PM, Antoine Beaupré wrote:
> Well, the friction is one thing, but we need to adopt *one* system for
> the future, if CVEs are going the wayside (or even as a complementary
> approach).
I agree with this post from oss-security:
https://marc.info/?l=oss-security=145764213513572=2
Fracturing of the security identifier space is inevitable and already
happening to some extent even before the CVE policy changes and before
OVE/OVI/DWF/etc started; many projects have their own identifiers and
some of those don't use CVEs (notably node-security and drupal
AFAICS). Here are some examples of project-specific identifiers:
https://anonscm.debian.org/viewvc/secure-testing/check-external/sources.ini?view=markup
I think Debian needs to go towards the approach of VRDX-SIG and do
identifier cross-referencing instead of settling on *one* system for
referring to security vulnerabilities. Internally, we would continue
to use CVEs and CVE-2016- for issues without CVEs and then map all
the external identifiers onto those.
> DWF seems interesting because it incorporates CVE IDs
> directly and it also allocates CVE ranges to various projects.
> Debian could be one of those:
>
> https://github.com/distributedweaknessfiling/DNA-Registry/blob/master/DNA-Registry.csv
>
> ... and manage its own allocations.
ETOOMUCHGITHUB :)
> I am not sure I like the CSVs, however... and it doesn't seem to have
> much adoption yet:
>
> https://github.com/distributedweaknessfiling/DWF-Database/blob/master/DWF-Database-2016.csv
More available here:
https://github.com/distributedweaknessfiling/DWF-Database/blob/master/DWF-Database-2015.csv
Wow, both of those really aren't useful at all; no external references
or actionable useful information.
Either way we need to support it since it is already being used. I
have a local branch of the security tracker that has a data/DWF/list
file containing the following. Ultimately though, I think that is the
wrong approach. Instead, data/CVE/list should continue to contain all
the data and we just add {DWF-2016-8 DRUPAL-SA-37134} to the
beginning of the entry like we do for DSA/DLA. Then the tracker needs
to grow support for extra security issue identifiers and we need a
script reading sources.ini and automatically pulling down each kind of
identifier and adding it to data/CVE/list, as we do for CVEs
themselves.
https://wiki.debian.org/SummerOfCode2015/ProjectProposals/SecurityTrackerCheckExternal
https://anonscm.debian.org/viewvc/secure-testing/check-external/sources.ini?view=markup
DWF-2016-89000 Fedora captcha system weakness
NOT-FOR-US
NOTE: https://patrick.uiterwijk.org/2016/03/09/fedora-spam-dwf-2016-89000/
DWF-2016-89001 [Shotwell does not validate TLS certificates]
- shotwell 0.22.0-3 (bug #807110)
NOTE: https://bugzilla.gnome.org/show_bug.cgi?id=754488
> Centralisation certainly doesn't scale here...
I think using debbugs or similar for CVE numbers could easily scale,
if a few features were added to it, but I doubt that will happen.
https://marc.info/?l=oss-security=145766818820035=2
--
bye,
pabs
https://wiki.debian.org/PaulWise
Re: tracking security issues without CVEs
On Sat, Mar 12, 2016 at 10:51 PM, Kurt Roeckx wrote: > On Sun, Mar 06, 2016 at 03:33:16PM +1100, Brian May wrote: >> For example, if there are no CVEs are we able to use OVEs instead? > > What abaout DWF? That didn't exist at the time of Brian's post. I think OVE/OVI still have less friction than DWF, you just need to press a button. -- bye, pabs https://wiki.debian.org/PaulWise
Re: tracking security issues without CVEs
On Fri, Mar 11, 2016 at 3:49 AM, Moritz Mühlenhoff wrote: > On Sun, Mar 06, 2016 at 06:58:48PM +0100, Salvatore Bonaccorso wrote: > >> But I think as well that is right now to early to >> start adopting these for not yet assigned issues. > > Agreed, let's stick with the usual "file a bug to get a temporary > identifier" procedure for now. I wonder if the TEMP URLs should redirect to the bug report URL when there is a bug available? BTW, there was an LWN article about the alternatives to CVEs: http://lwn.net/SubscriberLink/679315/a38e2baa9ceaf953/ -- bye, pabs https://wiki.debian.org/PaulWise
