[Mailman-Users] Mailman CSRF Vulnerability

[Lindsay Haisley]

On Thu, 2018-01-11 at 11:36 -0800, Mark Sapiro wrote:
> On 01/10/2018 08:47 PM, Lindsay Haisley wrote:
> > 
> > 
> > Upgrading MM2 here is a bit of a PITA since I have to do a lot of
> > patching to support the hacks I've done to MM over the years.
> 
> FWIW, the way I handle this is in the beginning, my production Mailman
> starts as a clone of the bzr branch at
> <https://code.launchpad.net/~mailman-coders/mailman/2.1>. I then apply
> local changes in that branch and commit them and then configure, make
> and make install it as usual.

I've thought of setting up a Launchpad private (non-merging) repository
with a MM2 copy including my various additions and mods and then
creating a branch copy of it in my local mailman src collection.
Periodically I could download the current published revision and merge
it into my private version so I'd be up to date without nuking my
personal patches and additions. This might create conflicts, though, if
my local patches conflicted with a change of the officially merged
version of some file, in which case there'd be a divergence which would
have to be manually sorted.

> Rarely, there will be a
> merge conflict that I have to resolve. Then in any case, I commit,
> configure, make and make install as usual.

Probably what I'm talking about.

> This makes updates fairly painless. I do this often and keep my
> production installs up to date with the HEAD, but I trust the guy doing
> the commits to the HEAD ;).
> 
> To be more conservative one could add a revisionspec like -rtag:2.1.25
> to the initial 'bzr branch' and likewise something like -rtag:2.1.26 for
> the 'bzr merge' to just stick to releases, all of which are tagged.

I only partially understand this, Mark. I'll need to sit down and study
it. Thanks!

-- 
Lindsay Haisley       | "The first casualty when
FMP Computer Services |         war comes is truth."
512-259-1190          |            
http://www.fmp.com    |     -- Hiram W Johnson