Let me add that there is another CVE (CVE-2016-4049) which may not apply to VyOS (I don't use BGP MRT, so I have no idea what the state of play is there).

In fact, the new quagga release today has only six changes, all of which are security issues even though not all have CVEs. I'd suggest that someone more familiar with current VyOS code take a quick look and port anything needed - at a guess, the isisd code may not port (it has had a ton of work since last import into Vyatta), while the BGP and OSPFv3 code may.

Here's the changelog, which is short and easily read: http://download-mirror.savannah.gnu.org/releases/quagga/quagga-1.0.20161017.changelog.txt

@syncer Did you read what I wrote??

There is nothing to port. The patch will apply cleanly. All you have to do is apply it.

@Alexis, sure, but don't have habit apply everything on first request from internet.

@syncer

1. It's one freaking line

2. It's not my patch, it's in the quagga repository

3. This is a *security* issue which needs urgent attention

4. It requires no special expertise to check this patch.

It's your project, and you'll obviously handle it however you like. But it is hard to comprehend NOT releasing a point update in response to this exploitable issue. Certainly there will be potential users of VyOS who will be deterred from using it because of the lax approach to security.

@Alexis Please don't panic. This bug is only exploitable if RA handling is enabled in quagga, and by default it is not. Setting interface's IPv6 to autoconf doesn't enable it in zebra either.
I agree it should be included in 1.1.8, but it's not urgent. I suppose we'll build 1.1.8 some time next week anyway, there are other issues to be addressed.

Also, for the current VyOS that uses image uprade, whether it's one line or not is, sadly, irrelevant, as you need to install a complete image if you go for the official upgrade. We need to find a way to make individual package upgrades possible, but it's a pretty hard task if we want to keep it perfectly safe but completely automated.

@Alexis By the way, if you are into the quagga source code, maybe you want to join the work on switching to the upstream or cumulus quagga and "forth-porting" vyatta changes to it?

@dmbaturin I'm glad to hear that you'll be releasing a new version soon.

My comment about it being one line was not directed at the complexity of the upgrade for end-users, but rather at the amount of review time it would take from a committer to understand and commit the patch.

I would suggest that at some point you're going to have to figure out how to handle security issues. Larger and more established projects have clear policies in place about releasing point updates in response to security issues. I recognize that this consumes valuable dev time and creates cognitive load, but I think it's inevitable if you want to be taken seriously by more people and organizations.

BTW, while I have your attention - can you say anything at all about plans or a timeline for importing all the changes in quagga? I spent some time a couple of weeks ago looking for info on that here and couldn't find anything. I know that that is of great concern to me (my organization is in early stages of working out a plan to revert to quagga for that reason), and I suspect for many others who might otherwise use vyos as well. In particular, anyone using ISIS, OSPFv3, newer BGP features, etc...

Thanks.

@dmbaturin Oops, started my reply before your second comment was posted.

I'm glad to hear that there's work going on to bring newer versions of quagga code into VyOS. And I don't envy you the choice of cumulus versus mainline, it's a tough call. I would again encourage you to post about that effort somewhere obvious, as it is really important to many users and potential users of VyOs.

I'm afraid I'm not at all into the Quagga source - I've only ever looked at it twice, the second time being when I examined the patch I posted about. Also, I'm at least ten years out of practice writing anything "real" in C, so I'm not especially qualified to do that work.

@Alexis I wish, with this shortage of contributors, we were really in position to make specific plans regarding the timeframe. ;)
This also applies to the security updates issue. We really need a dedicated security watcher, but, sadly, no one wants to take up this role, so it's always done in a haphazard manner, which is a bad experience for both end users and developers, but that's what we've got.
In a few years of project life, the number of people committed to using VyOS in production grew, but the number of people committed to developing it almost did not, it's still just a few people who have to do everything, and, frankly, it's taxing. At this point, none of us can turn it into a full time job (the commercial support thing @syncer and I started may change it in the future and give some of the maintainers guaranteed N hours a week to spend on it, but it's still a very early stage).

I guess my comment is degenerating into a rant, but my point is, if you care about quagga, I'll be absolutely happy if you contribute your time towards it. We really need more people to get actively involved in the development to make it happen.

@dmbaturin I understand, and I didn't mean to be someone just grousing from the sidelines. My evaluation of that specific patch is the most I can offer at the moment.

About porting in the quagga changes - I wasn't asking for a specific timeline. I can see you guys are stretched thin. What I'm asking for is a statement of direction. Until your comment earlier today I didn't even know if this issue was even on your radar at all. That's a pretty important matter, and it deserves to be on your roadmap, or the front page of the wiki, or some other obvious place.

Sent pull request. This thing is really trivial. @Alexis, would be so kind to that resulting package is ok? My building appliance is somewhat disabled right now and I have only a tiny amount of time to do recreate it, so I will be able to test that everything is ok next week only, sorry.

@mickvav Sorry, I don't have a build environment set up right now. I opened this ticket mostly as a service to the VyOs commmunity since nobody on the quagga side had gotten around to alerting you.

BTW, since the initial CVE, I've realized that the alert is extremely confusing (though the condition for avoiding the exploit is stated correctly, so that's good at least), and I'm working with them now to correct/update it.

@Alexis , I've got my build environment up and running and created .deb's for this issue. Feel free to test.

N.B. @dmbaturin, @syncer I've found that vyatta-quagga package is not listed in git submodules of vyos-build. It seems to be a bug.

Pull request - https://github.com/vyos/vyatta-quagga/pull/5
Anybody tested this .debs?

Fixed in helium branch for 1.1.8: https://github.com/vyos/vyatta-quagga/commit/e18428d724ba20af4d9282a90900de8d96758610