* Matthew Toseland <toad at amphibian.dyndns.org> [2008-12-13 11:24:12]:
> On Friday 12 December 2008 23:07, Florent Daigni?re wrote: > > > I'm not really trying to discuss how the builds should be signed > > > (another discussion really), > > > > No, it's not. THEY SHOULD NOT BE SIGNED ON EMU EITHER! and it's not > > because we are doing it wrong at the moment that we should extend the > > "bad" behaviour. > > You criticised me for inserting my own builds rather than emu's, on the > grounds that emu's builds are more easily verified. Now you say installers > should be totally bereft of any form of verifiability, compiled on a dev's > private machine using his private JVM? Or that they should be generated on > emu and then signed on a dev's private machine, which would be even worse as > it gives two possibilities for compromise? > Most security "problems" are related to priviledge escalation; in one case you get to execute code on new nodes, on the other you get to execute code on exisiting nodes: those are two different priviledges. Why? because in case one of those two system is compromized, you'll have to use the second to bootstrap a new, clean trust chain. > I know you privately think we shouldn't distribute any binaries whatsoever, > but practically speaking what is your proposed architecture here? > > I've explained it in the other thread. > > > but trying to figure out why you can sign > > > the compiled .jars, but not the compiled .exe installer? > > > > jarsigner is bundled in any jdk; I don't know any PE signer for linux. > > Nor an open source command line PE signer that can run on Wine? > > I'm not supposed to be the windows guy here. As far as I know they are tools which come with M$'s SDK which is everything but OSS. > > > >> 2) The topic wasn't really about which platform to pack on, but if to > > > >> build and pack on the same platform. It isn't preferred to build > > > >> applications for platform A on platform B, but since we have 1 emu, > > > >> which runs platform B, we will have to do with that. AHK is supported > by > > > >> Wine, which runs on Linux, so I don't really see the big problem > > > >> (besides spending time installing Wine, which we already have an > > > >> argument going on about) > > > > > > > > You are thinking about your installer here and not others. Tomorrow > > > > sanity will want his macos installer to be built there too; how do you > > > > do that? What about win64? ... > > > > > > So because we have the possibility to do improvements for one platform, > > > we shouldn't - because we might not be able to do so for all the other > > > platforms? I'd say thats a poor policy. I think it is just fine to use > > > native installers where possible, and fall back to a generic for > > > platforms we cannot support with native installers (or packages, or dmg > > > files or whatever). > > > > I don't care what you'd say. You are pushing for infrastructure changes > > to be made: you are the one making demands here. The policy is what it > > is: special cases suck and should be avoided. It's not like there wasn't > > any alternative. > > The current installer sucks. Zero3's proposed installer will be much quicker, > in the sense that the user will no longer have to click next 6 times. For > Windows, that's an improvement. > > On the other hand, the current installer is quite acceptable for linux until > we have packages, for OS/X until we have some OS/X developers, and for > distros for which we don't have packages. It is easier to correctly use than > a tarball. > > > > > > > > I happen to be familiar with both the installation-related issues and > > > > the infrastructure ones and that's why the debate is mostly in between > > > > you and me. The catch is that I am not willing to spend time on it; I am > > > > not interested by native installers anymore. > > > > > > If I look back at the discussions we've had the last couple of weeks, > > > I'd say you have been acting like that from the start of. Hell, even > > > back when I wrote the Windows update script I met the same attitude. > > > > > > Good thing that other people can look into it when you don't want to, > then. > > > > Don't worry: that's the last reply you will get from me. I have more > > important things to spare my free time on. > > Okay so you concede. I'll install a Windows VM on emu then! :) > > Seriously, if you don't want to maintain emu, it will cost me a whole load of > work and a lot more reading, PLEASE TELL US, leaving emu without anyone > maintaining it is unacceptable. > I am maintaining it as long as no one is doing something silly behind my back. "apt-get install wine" is silly. > And I would just like to point out again that nextgens has done a lot more > for > FPI than any other active volunteer developer, although lately he has been > sulking and talking about leaving. His views have to be taken into account. > But so do Zero3's, especially if nextgens keeps to his repeated threat of > leaving. I'm not threatening about anything: I told you that I have reconsidered my involvment with the project and in practice that means I'm spending less time on it. Now if most of it is wasted argueing over things I took for granted and understood by everyone, I might re-reconsider my position and vanish completely, yes. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20081213/e27556c0/attachment.pgp>
