Re: [gentoo-dev] git security (SHA-1)
On Mon, Sep 15, 2014 at 12:35 PM, hasufell wrote: > Jauhien Piatlicki: >> Hi, >> >> On 09/15/2014 01:37 AM, Kent Fredric wrote: >>> On 15 September 2014 11:25, hasufell wrote: >>> Robin said > The Git commit-signing design explicitly signs the entire commit, including blob contents, to avoid this security problem. Is this correct or not? >>> >>> I can verify a commit by hand with only the commit object and gpg, but >>> without any of the trees or parents. >>> >>> https://gist.github.com/kentfredric/8448fe55ffab7d314ecb >>> >>> >> >> So signing of git commits does not guarantee enough security (taking >> that SHA1 is weak and can be broken), right? Could we than just use >> usual (not thin) manifests? >> > > * there is no known SHA-1 collision afais > * calculating one isn't that hard. NSA might be able to do it in > reasonable time > * however, the algorithms to do that will come up with random garbage, > so it's a completely different thing to hide a useful vulnerability > behind a SHA-1 collision > sha-1 has is not directly a security feature, rather merely consistency check (albeit it has some security implications). hash is generated by using hash of commit parent and is checked every time you pull. You can actually take master commit and hash and then recursively check whole tree (albeit only basic check from current head parent is done when you pull, assuming that local tree is intact). Corrupting a single commit should be easy enough, but since the system is decentralised, people who you pull from should catch that attempt automagically. At least that's my understanding of how git (mercurial) works. Linus himself sums it nicely here: https://www.youtube.com/watch?feature=player_detailpage&v=4XpnKHJAok8#t=3375 T.P.
Re: [gentoo-dev] Re: LTO use in the tree
>should not cause any issues (provided compilation goes through). There are few packages which compile fine but break something (I remember some x11-library from bugzilla that broke xorg-server), but generally I agree with you. One annoying package is 64bit firefox, which can easily eat up to 15GB of memory (!!!), at least with gcc 4.8, newer 4.9 branches are said to have fixed this, but since it required complete rework of LTO, new bugs were inevitably introduced. > OTOH, there are already projects like sqlite which have essentially only one compilation unit, anyway. Thats absolutely correct, there is one sqlite.c file which is split into logical parts for easier code hacking, but it's one file. Interestingly, even sqlite seems to be benefiting from LTO, binary is 5% smaller on my system. On Mon, Apr 28, 2014 at 10:25 AM, Martin Vaeth wrote: > C. Bergström wrote: > > Can you name a single package that you use which receives a measurable > > benefit from LTO? (Just asking) > > Like for every optimization flag, it is easy to construct particular > examples: It can help a lot if e.g. a user's string-helper library > is inlined. Concerning memory, it can help a lot if duplicate data > (e.g. macros containing paths) from different compilation units > can be merged. > I guess (though I did no benchmarks) this is why eix profits so much > from LTO: it was already mentioned that eix's size is *considerably* > smaller with LTO. > Surprisingly, eix does almost not profit from clang's LTO. > I guess it is not the different implementation of LTO but of > the remaining optimizers which make the difference here. > Again: These are just guesses, I never tried to analyze. > > I use it globally, because LTO *can* help a lot and should never > hurt performance if the remaining optimizers are good and > should not cause any issues (provided compilation goes through). > The price is clear: More than doubled compilation time (which takes > place in the linking phase and thus cannot be ccache'd) and for some > packages insane memory requirements which forbid its usage on some > systems. > > > IPA (aka whole program and LTO) is by far the hardest optimizations > > I've ever personally had to debug/engineer/tune in a compiler. > > Making it robust [... > > I guess it is not a problem by itself: It just triggers cases > which "in practice" do not occur otherwise, since most developer's > will typically write relatively small compilation units. > So you just now you see the bugs hidden in the algorithms which > before never were found... > OTOH, there are already projects like sqlite which have essentially > only one compilation unit, anyway. (I am guessing this only from > the output shown during compilation, so I might be wrong.) > > >
Re: [gentoo-dev] Proper distribution integration of kernel *-sources, patches and configuration.
This reminds me of: http://imgs.xkcd.com/comics/standards.png It sure sounds nicely, however I would not want to be the guy who maintains the whole mess of (often) incompatible patchsets. Given the fact that some patches lag 1-3 stable versions behind Linuses tree (grsec used by hardened for example), this might be better idea on paper than in reality. If you feel up for this, go for it. Be ready to meet resistance though. // I personally maintain my own tree, based on stable from gregkh and few patches On Mon, Jul 1, 2013 at 4:41 PM, Tom Wijsman wrote: > Hello > > > Please reply to gentoo-dev in case ML daemon changes Reply-To. > > > ### TL; DR ### > > By introducing feature patches which menu options are disabled by > default to genpatches, we can deduplicate *-sources maintainers as well > as large groups of users work. By introducing a distribution section > in the menuconfig, we can provide options that enable minimal Gentoo > requirements by default (DEVTMPFS, making Gentoo systems bootable since > an udev release a long time ago) and other distribution stuff. > > > ### Proper distribution integration of kernel *-sources, patches ... ### > > Gentoo is a distribution; but what is a distribution that doesn't > properly integrate what it provides, but instead expects its users to > do so, needlessly duplicating work amongst its maintainers and users. > > Let's say I want genpatches, aufs and TuxOnIce; closest candidates: > > - sys-kernel/aufs-sources: genpatches, aufs > - sys-kernel/pf-sources: genpatches, CK, BFQ, BFQ, TuxOnIce, UKSM > - sys-kernel/tuxonice-sources: genpatches, TuxOnIce > > What do I do? Take one (eg. aufs) and apply the other (eg. TuxOnIce)? > What if I want to add another common patchset to it? Hardened perhaps? > > You can see, some of these sources (like pf-sources) already attempt to > do so; with pf-sources in mind, why do we even have ck-sources, > tuxonice-sources in the Portage tree? Just to duplicate work? > > I think we should trim down on the amount of *-sources and combine > multiple patches into genpatches. Take an example of geek-sources > which does all this without a problem; I don't really like the approach > with USE flags used there, as the menuconfig can just cover that. > > https://github.com/init6/init_6/wiki/geek-sources > > What does a patch introducing new features really do? Or rather, what > should it do when we add it? Let me summarize: > > 1) The features should be disabled by default. > 2) These feature should depend on a non-vanilla / experimental option. > 3) The patch should not affect the build by default. > 4) The user can optionally enable the feature. > > So, in genpatches, since 3.9.7, BFQ was added to try this out (except > 2.). Ensured it to be disabled by default, did not affect the build for > anyone that does not enable it and the users have been enabling and > using it on their own. So, does it differentiate more from vanilla? No. > > This helps users as well as maintainers to not have to apply BFQ on > their own, they simply have to tick a config option and they are set. > If all patches that introduce new features are added in this fashion, > it spares large groups of users from having to do this on their own; we > can also deduplicate the work in the Portage tree this way. > > > ### ... and configuration. ### > > This problem is not only visible for patches, but also in the config. > > Meet CONFIG_DEVTMPFS; forget to enable it, greet a failing boot. We're > telling users to enable it in some places, in the handbook it's a single > line you must read, on the Wiki it's kind of missing unless you are > luckily on the right page, on the Quick Install book it is missing too. > > So, we are currently providing a configuration that expects anyone to > enable CONFIG_DEVTMPFS. But you have to remember that it need to make > sure you read about it or enable it from the udev upgrade a while ago > if you decide to start from a fresh config or are installing without > that handbook you kind of have memorized. > > Searching for CONFIG_DEVTMPFS in the forums and #gentoo logs shows that > this is quite often suggested as a fix and quite often actually fixes > an user's boot. Why duplicate telling users to do that if we can do it? > > There are a small set of other variables in this nature, mostly *TMPFS*. > > This is why I think it would be handy to add a Gentoo section to the > kernel, along the lines as described by Linus. > > https://lkml.org/lkml/2012/7/13/369 > > The same goes for asking the user to enable configuration options in the > kernel, why can't we just tell him to enable all option that toggles > support for the user. For example; in the Gentoo section, there would be > a "Init System Support" under which you can toggle an option to support > the minimal requirements for some init system. > > Feedback is very welcome. > > P.S.: Not everything in this mail has been acked by the kernel lead; > only some thoughts, I was suggested
Re: [gentoo-dev] Questions about SystemD and OpenRC
Not really, Linus has his own web of trust and he don't take stuff from unknown sources, he has his liutennants and every single patch and change must be reviewed by at least two other maintainers below Linus. After all, Linux does not belong to Linus and his branch is by definition of distributed system no better than yours. Exception being is that he generally makes right decisions and can be reason with. It would be much simpler to push _good_ feature into kernel than into gentoo [imho]. @systemd: I liked it in it's early stages but every month code gets more and more bloated and for (to me) unknown reason it's slowing on my machine every new version. It also did not deliver on promise of stability as early scripts I wrote don't work with latest version. On Thu, Aug 9, 2012 at 8:53 PM, Canek Peláez Valdés wrote: > On Thu, Aug 9, 2012 at 1:31 PM, William Hubbs wrote: >> On Thu, Aug 09, 2012 at 11:12:46AM -0700, Olivier Crête wrote: >>> > Most ideas behind systemd are interesting, their current implementation >>> > is sometimes completely wrong and given the experience with pulseaudio >>> > we all know that they won't change even if you provide code for it. >>> >>> This is bullshit, if you have good reasoned arguments, Lennart is a very >>> reasonable guy, but if you just say "your ideas are shit, you code is >>> terrible", then yes, he'll just ignore you. >> >> Sorry to call you on this one, but that is not the experience I had. >> >> I proposed adding configure switches to their build system to accomodate >> source base distros, such as gentoo, who at times want to use udev >> without systemd. I even went out of the way to make sure that I didn't >> change their default settings. >> >> Look at a thread on their ml called minimal builds along with their wiki >> page on minimal builds for Lennart's answer. He even went so far as to >> say that our package managers are broken, and there was absolutely no >> negotiating this point. We are wrong as far as he is concerned. > > By the same reasoning, Linus is even a bigger asshole. In the kernel > they flatly refuse to merge code from a LOT of people; that's their > job in the end. > > I read the thread where you proposed the changes to systemd's build > system. I wish it was accepted, but I also understand why they didn't. > As I said in other threads, they really don't care for source based > distros; and that sucks for Gentoo (and every other source based > distro), but it's their call. And it certainly helps them to keep the > build system simple, assuming that it would be used only by packagers > for binary distros. > > That doesn't say anything about the design of systemd, which is why I > use it; not because of the build system. > > Regards. > -- > Canek Peláez Valdés > Posgrado en Ciencia e Ingeniería de la Computación > Universidad Nacional Autónoma de México >
