Development mailing list

Syndicate content
Archive of posts for haiku-development at FreeLists
Updated: 25 min 16 sec ago

[haiku-development] Re: RFC: Media plug-ins hybrid support (Axel Dörfler)

Wed, 2014-04-23 16:45
On 04/01/2014 03:04 PM, PulkoMandy wrote: What would you suggest? As we currently only have a single add-on, moving it client side definitely sounds like an option. However, I think another option would also be acceptable: ...
Categories: Development

[haiku-development] Re: No nightlies (John Scipione)

Wed, 2014-04-23 16:45
Dancsó Róbert wrote: I see there are no nightly images since day. The last was on 26 of March. Can somebody check it? The problem as I understand it is that we switched from using nasm to yasm in hrev47066 so we need to re-run configure in order to make it ...
Categories: Development

[haiku-development] Re: RFC: Media plug-ins hybrid support (Jessica Hamilton)

Wed, 2014-04-23 16:45
On 2 April 2014 02:04, PulkoMandy pulkomandy@xxxxxxxxx wrote: Hello there, During my work on adding HTML5 audio/video to WebKit, I hit an issue with the design of the Media Kit and the way plugins are loaded. I'm not talking about media add-ons, these live only in the media_server and work fine. I'm talking about plugins, which are used for decoding and encoding audio and video files. We currently have a single one that uses ffmpeg to decode all formats we support. ...
Categories: Development

[haiku-development] RFC: Media plug-ins hybrid support (PulkoMandy)

Wed, 2014-04-23 16:45
Hello there, During my work on adding HTML5 audio/video to WebKit, I hit an issue with the design of the Media Kit and the way plugins are loaded. I'm not talking about media add-ons, these live only in the media_server and work fine. I'm talking about plugins, which are used for decoding and encoding audio and video files. We currently have a single one that uses ffmpeg to decode all formats we support. Unlike add-ons, the medi plugins are loaded in the application memory ...
Categories: Development

[haiku-development] No nightlies (Dancsó Róbert)

Mon, 2014-04-21 11:45
...
Categories: Development

[haiku-development] Re: Design for signed packages (Ari Haviv)

Mon, 2014-04-21 11:45
On Sun, Mar 30, 2014 at 11:38 AM, Ingo Weinhold ingo_weinhold@xxxxxxwrote: On 03/27/2014 09:42 PM, Jonathan Schleifer wrote: There were even complains that I replaced a completely broken hash! Actually you introduced the only completely broken hash so far -- the file size. As I already wrote on the haikuports-svn list, MD5 is not broken for our purpose, since there's no know practical preimage attack. ...
Categories: Development

[haiku-development] Re: Design for signed packages (Ingo Weinhold)

Mon, 2014-04-21 11:45
On 03/28/2014 06:15 PM, Jonathan Schleifer wrote: Am 28.03.2014 um 15:46 schrieb Stephan Aßmus superstippi@xxxxxx: That's not what this is about however, its about verifying the authenticy of the entity requesting a certificate. … that, however, is more likely and I see no problem with that. ...
Categories: Development

[haiku-development] Re: Design for signed packages (Ingo Weinhold)

Mon, 2014-04-21 11:45
On 03/27/2014 09:42 PM, Jonathan Schleifer wrote: There were even complains that I replaced a completely broken hash! Actually you introduced the only completely broken hash so far -- the file size. As I already wrote on the haikuports-svn list, MD5 is not broken for our purpose, since there's no know practical preimage attack. ...
Categories: Development

[haiku-development] Re: Design for signed packages (Ingo Weinhold)

Thu, 2014-04-17 11:45
On 03/28/2014 09:28 PM, Jonathan Schleifer wrote: There's also choice 3: Showing the dialog like in Choice 1, but showing which other certificates signed the certificate. Then the user can still decide. Thank you, that's exactly what I proposed. ...
Categories: Development

[haiku-development] Re: Design for signed packages (Ingo Weinhold)

Wed, 2014-04-16 15:45
On 26.03.2014 22:49, Jonathan Schleifer wrote: Am 26.03.2014 um 22:29 schrieb Ingo Weinhold ingo_weinhold@xxxxxx: How is supporting multiple algorithms in one format different from supporting different formats versions with one algorithm each in this respect? In either case the older algorithm can easily be disabled when it is no longer considered secure. ...
Categories: Development

[haiku-development] Re: Design for signed packages (Ingo Weinhold)

Wed, 2014-04-16 09:45
On 26.03.2014 21:47, Jonathan Schleifer wrote: Am 26.03.2014 um 21:19 schrieb Ingo Weinhold ingo_weinhold@xxxxxx: On 26.03.2014 04:08, Jonathan Schleifer wrote: Am 25.03.2014 um 21:55 schrieb Ingo Weinhold ingo_weinhold@xxxxxx: ...
Categories: Development

[haiku-development] Re: Please don't require cmd:gcc / cmd:g++ in recipes (Andrew Hudson)

Tue, 2014-04-15 23:45
Yes, currently, clang calls gcc for linking, which would result in calling itself then ;). Lol! There's something very, recursive and poetic about that. ...
Categories: Development

[haiku-development] Re: Please don't require cmd:gcc / cmd:g++ in recipes (Jonathan Schleifer)

Mon, 2014-04-14 16:45
Am 29.03.2014 um 21:48 schrieb Axel Dörfler axeld@xxxxxxxxxxxxxxxx: Am 28/03/2014 22:42, schrieb Jonathan Schleifer: … and use cmd:cc / cmd:c++ instead. As long as the two aren't completely compatible and interchangeable (as in drop-in replacement), Clang is designed as a drop-in replacement indeed. And that works for most software quite well. The exception is software that depends on heinous GNU ...
Categories: Development

[haiku-development] Re: Please don't require cmd:gcc / cmd:g++ in recipes (Axel Dörfler)

Mon, 2014-04-07 19:45
Am 28/03/2014 22:42, schrieb Jonathan Schleifer: … and use cmd:cc / cmd:c++ instead. As long as the two aren't completely compatible and interchangeable (as in drop-in replacement), that change doesn't make sense (as they actually could not be built with clang), and if they are, it's not needed, as clang could just provide g++ and gcc, too. ...
Categories: Development

[haiku-development] Please don't require cmd:gcc / cmd:g++ in recipes (Jonathan Schleifer)

Mon, 2014-04-07 11:45
… and use cmd:cc / cmd:c++ instead. The reason is that currently, each of our recipes depends on GCC, even though I'm sure many could be built with Clang. GCC already provides cc and c++, and so could Clang do. New platforms could theoretically be Clang only (I'm considering doing that for PPC, as our GCC is currently giving problems there) and this would also make using Clang easier (if we want to go that route - maybe this is something we should vote on). -- ...
Categories: Development

[haiku-development] Re: Design for signed packages (Jonathan Schleifer)

Sun, 2014-04-06 23:45
Am 28.03.2014 um 22:12 schrieb Urias McCullough umccullough@xxxxxxxxx: I just think that we can solve Jonathan's concerns right away by adding a list of hashes for each of our downloaded packages used at build time in our Git repo and verifying them on download... whereas adding a full signing mechanism will take longer. Actually, it's part of the solution. We would need to throw away all current packages and do a new bootstrap build, then rebuild them all. Why? Because if we fix the issue, we still can't know if it didn't already happen. The NSA has ...
Categories: Development

[haiku-development] Re: Design for signed packages (Urias McCullough)

Sun, 2014-04-06 09:45
On Fri, Mar 28, 2014 at 2:06 PM, Julian Harnath julian.harnath@xxxxxxxxxxxxxx wrote: Urias McCullough umccullough@xxxxxxxxx schrieb: I don't understand how that's significantly different from simply maintaining hashes of all the binaries in our source control and verifying them during download. There's really no need to sign them assuming we trust devs who have commit access already. The advantage of signing over a simple hash is that it depends on the private key, which is well, private. An attacker who could gain access ...
Categories: Development

[haiku-development] Re: Design for signed packages (Julian Harnath)

Sun, 2014-04-06 02:45
Urias McCullough umccullough@xxxxxxxxx schrieb: I don't understand how that's significantly different from simply maintaining hashes of all the binaries in our source control and verifying them during download. There's really no need to sign them assuming we trust devs who have commit access already. The advantage of signing over a simple hash is that it depends on the private key, which is well, private. An attacker who could gain access to our package repo server could simply exchange the binaries and change the hashes. It's also easy to do a man-in-the-middle attack, changing ...
Categories: Development

[haiku-development] Re: Design for signed packages (Urias McCullough)

Sat, 2014-04-05 16:45
On Fri, Mar 28, 2014 at 1:25 PM, Jonathan Schleifer js-haiku-development@xxxxxxxxxxx wrote: Well, I didn't want to stop after signed packages. But that was what I deemed the most necessary step, as every developer downloads unsigned packages during the build process and then later uploads packages. So all that's needed to plant a backdoor in Haiku is controlling the internet connection of a single developer once. I don't understand how that's significantly different from simply maintaining hashes of all the binaries in our source control and ...
Categories: Development

[haiku-development] Re: Design for signed packages (Jonathan Schleifer)

Sat, 2014-04-05 14:45
Am 28.03.2014 um 20:46 schrieb Julian Harnath julian.harnath@xxxxxxxxxxxxxx: Jonathan Schleifer js-haiku-development@xxxxxxxxxxx schrieb: Am 28.03.2014 um 15:46 schrieb Stephan Aßmus superstippi@xxxxxx: It can't verify that the software contains no viruses or backdoors. Exactly. That was why I was against signing certificates … That doesn't make sense, if software is malicious or not has nothing to ...
Categories: Development