Opened 15 years ago
Closed 15 years ago
#2597 closed task (fixed)
Update vim-7.2-fixes-5.patch
Reported by: | Steffen Pankratz | Owned by: | Matthew Burgess |
---|---|---|---|
Priority: | normal | Milestone: | 6.7 |
Component: | Book | Version: | SVN |
Severity: | normal | Keywords: | |
Cc: |
Description
This patch contains upstream patch numbers 1 thru 239. Upstream has a lot of new ones (latest is 381).
Change History (8)
comment:1 by , 15 years ago
comment:2 by , 15 years ago
What about some script which updates the patch every time before the book is generated?
comment:3 by , 15 years ago
I thought I remembered someone saying that the patches available on the Vim site were effectively their VCS, i.e. taking their patches & applying them in the book is equivalent to doing an svn/git checkout of trunk. So, we may in actual fact want to drop the patch entirely. I can't find the email chain that discussed this at the moment.
Looking at http://vim.svn.sourceforge.net/viewvc/vim/vim7/src/version.c?revision=1780&view=markup it looks like by picking up the latest patch, 382, we'd actually be ahead of what's even committed in their SVN repo (376).
My proposal would therefore be to drop the patch entirely.
As to kratz00's suggestion - one of our quality gates is that the book still builds a functioning system prior to each commit. I already have a script that generates a consolidated Vim patch based on all of upstreams patches, so that bit's not too bad at all. It's the building of a full system just to test that upstream's latest development changes haven't broken anything that would take time, which I'm sure is better spent elsewhere.
comment:4 by , 15 years ago
I agree with Matt. I propose closing this ticket as wontfix. We can leave the current set of patches in the book until the next vim release and then remove the patches completely.
New patches then should only be added for major functionality or build errors or security issues. For vim, I don't recall ever happening.
comment:5 by , 15 years ago
Security issues happen in vim. Severity depend on the machine usage.
Just for 7.2, the list is not small. Look at CVE-2008-6235 CVE-2008-3076 CVE-2008-3075 CVE-2008-3074 CVE-2009-0316 CVE-2008-4677 CVE-2008-4101
comment:6 by , 15 years ago
Gilles,
CVE-2008-6235 - netrw.vim not patched upstream yet
CVE-2008-3076 - netrw.vim not patched upstream yet
CVE-2008-3075 - same root cause as 3074
CVE-2008-3074 - same root cause as 3075 - isn't identified in CVE DB though
CVE-2009-0316 - patched in upstream patch 045
CVE-2008-4677 - netrw.vim not patched upstream yet
CVE-2008-4101 - patched in upstream patch 010
So, out of 7 vulnerabilities I can only be confident of fixing 2 of them. 3 haven't been addressed upstream, from what I can tell, and 2 don't even allude to where the problem lies. Checking whether upstream has fixed those is impossible as none of their patches contain CVE numbers!
Just cherry picking the 2 CVE fixes we know about and putting them in the book would, I suspect, give our users a false sense of security. So, I stand by my original assertion that we shouldn't patch Vim at all.
For anyone interested, my Vim patch generation script is now at http://www.linuxfromscratch.org/~matthew/genVimPatch.sh
comment:7 by , 15 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
Perhaps we should put a note in the book pointing to the patches page and let the user decide what patches to apply. Many of the patches are for non-linux systems.
The number of patches implies to me that the list changes almost daily. There is no practical way to keep up.