lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1446656.4HCLD295vV@sifl>
Date:	Wed, 18 Jun 2014 14:26:27 -0400
From:	Paul Moore <paul@...l-moore.com>
To:	Stephen Rothwell <sfr@...b.auug.org.au>
Cc:	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: linux-next: the selinux tree needs cleaning up

On Wednesday, June 18, 2014 08:40:46 AM Stephen Rothwell wrote:
> Hi Paul,
> 
> The selinux tree (git://git.infradead.org/users/pcmoore/selinux#next)
> contains some commits going back to January and also has merges of
> v3.13, v3.14 and v3.15 in it.  If you rebase that tree onto v3.16-rc1,
> you find that it has onlt 2 unique commits (the most recent 2) which
> means that the others were merged upstream after being rewritten.  :-(

Without going through each of the differences between the SELinux tree and 
what is in Linus' tree in this email, I can assure you there is nothing 
nefarious going on here, just some differences in tree management between 
James' Linux Security tree and the SELinux tree which resulted in some 
backports and other mess.  The good news is that James' and the rest of us 
under the Linux Security tree have now established a protocol moving forward 
which should avoid these nasties.

So, back to your concerns - what do you want to see in linux-next?  My 
practice for the SELinux #next branch has been to apply patches on top of the 
latest "major" release from Linus, e.g. 3.15, and when a new major release is 
made I merge it into #next and restart the process.  I generally send James' a 
pull request in the -rc6/7 timeframe using the #next branch.  While this has 
resulted in some ugliness (see above comments) it keeps the SELinux #next 
branch steady so others can pull from it without major problems.

Does this approach not work for you and linux-next?

-- 
paul moore
www.paul-moore.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ