[coreboot] New on blogs.coreboot.org: Results of the coreboot "Mailing List vs Blog" poll

[WordPress]

A new post titled "Results of the coreboot "Mailing List vs Blog" poll" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2017/03/04/results-of-the-coreboot-mailing-list-vs-blog-poll/

A little while back, there were a few requests to switch from the mailing list format to a web-based forum for our official communication channel.  The coreboot leadership wanted to see what the actual preferences of the coreboot community was, so I posted a poll.  The poll was publicized in IRC and on the mailing list itself, so should have been communicated to the people who would be most directly affected by any change.
Poll results
Here are the overall results from all responses:
All_responses
We had a total of 60 valid responses, and I think the overall results pretty clearly indicate that the coreboot project should NOT move away from the mailing list.
One suggestion was to split the communication into the mailing list for Developers, and a forum for non-developers. To see what the various groups thought, I made a few more charts:
Developer preferences:
Developer Responses
So not unexpectedly, the coreboot developers even more overwhelmingly prefer the mailing list to the general results
Non-developer preferences:
Non-developer Responses
So even within the non-developer group, there was a definite preference for the mailing list format.
Finally, I broke the Non-developer group down into the group that said they were coreboot users, as opposed to those that mainly read the mailing list.
coreboot users (non-developers):
 
coreboot Users (Non-Developers)
That group had the highest percentage of people who preferred the forum, but it was still well under 40%.
Suggestions
We also asked people what we should do to improve the mailing list.  Here’s a summary of the suggestions:

Show people how to set up their (or a different) email client to make reading the mailing list easier.
Have people be more polite.
Add a FAQ showing previously asked question and answers.
A netiquette should be established like on the Linux kernel mailing list.
Several suggestions to improve the coreboot mailing list archive at https://www.coreboot.org/pipermail/coreboot/

Fix the archive so that long threads aren’t spread into different sections by months.
Add a search function to the archive
Create monthly archives that can be downloaded (This exists.)
Update from Pipermail to a more modern archiver like Hyperkitty – https://pypi.python.org/pypi/HyperKitty



Since it doesn’t look like we’re going to switch to a forum, I’m not going to list the suggestions that people had for that.
Follow-up
Over the upcoming weeks, we’ll look at our options, and discuss our options and plans in the bi-weekly coreboot community meetings.


-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Flash second/dual bios chip on Gigabyte G41M-ES2L without external flasher possible?

[i1w5d7gf38keg]

Is it possible to flash the second flash chip on the Gigabyte G41M-ES2L 
mainboard without external flasher?
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] call on AMD to release src+specs+datasheets for ryzen

[Nico Huber]

On 04.03.2017 17:54, taii...@gmx.com wrote:
> On 03/04/2017 06:39 AM, Nico Huber wrote:
> 
>> On 04.03.2017 02:57, taii...@gmx.com wrote:
>>> Of course they also must release the signing keys as well afaik, or we
>>> would be stuck at a tivo style not really open source impasse.
>>> Nobody has mentioned this fact in that thread.
>> Please don't ask for that.
>>
>> If somebody put a signature verification for his firmware in place, you
>> should first discuss the reasons and alternatives (for the particular
>> design in question). Sure there are alternatives to signature verifi-
>> cations to put some trust in hardware (like ROMs or the RO partitions
>> in cros devices). But removing the security checks from hardware who's
>> trust is designed around these checks? You'd likely end up with a sys-
>> tem where you have to check the flash contents with external hardware
>> before every boot (if it can be tampered with from the running system).
>>
>> Of course you can ask for alternatives in new designs.
>>
>> For yet released platforms, however, it's more feasible to ask for docu-
>> mentation, reproducible binaries and signatures (e.g. for fixes / reim-
>> plementations).
>>
>> Nico
>>
>>
> I am simply stating that source code is pointless without the ability to
> flash it and have the hardware execute it.

That's why I'd ask for documentation and reproducible binaries. You
could audit it then and wouldn't have to bother yourself with any fla-
shing.

> 
> The issue isn't that there are signing keys in the first place (which
> are common sense to prevent rogue BIOS updates) it is that the hardware
> enforces them for manual external flashes.

Correct. And that's why publishing the keys wouldn't solve the problem.
You'd just replace one problem with another.

> 
> Your idea isn't a free platform, it isn't owner controlled because you
> can't modify it

Yes, not a free platform. We are talking about AMD here. Releasing pri-
vate keys won't make it free. It would just make it less secure, IMO.
Btw. not my idea of any platform. Just my suggestion how to make cur-
rent platforms more trustworthy.

> - you can only be on the outside looking in.

Better nobody (including myself) can tamper with my system than every-
body.

Nico

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] call on AMD to release src+specs+datasheets for ryzen

[taii...@gmx.com]

On 03/04/2017 06:39 AM, Nico Huber wrote:


On 04.03.2017 02:57, taii...@gmx.com wrote:

Of course they also must release the signing keys as well afaik, or we
would be stuck at a tivo style not really open source impasse.
Nobody has mentioned this fact in that thread.

Please don't ask for that.

If somebody put a signature verification for his firmware in place, you
should first discuss the reasons and alternatives (for the particular
design in question). Sure there are alternatives to signature verifi-
cations to put some trust in hardware (like ROMs or the RO partitions
in cros devices). But removing the security checks from hardware who's
trust is designed around these checks? You'd likely end up with a sys-
tem where you have to check the flash contents with external hardware
before every boot (if it can be tampered with from the running system).

Of course you can ask for alternatives in new designs.

For yet released platforms, however, it's more feasible to ask for docu-
mentation, reproducible binaries and signatures (e.g. for fixes / reim-
plementations).

Nico


I am simply stating that source code is pointless without the ability to 
flash it and have the hardware execute it.


The issue isn't that there are signing keys in the first place (which 
are common sense to prevent rogue BIOS updates) it is that the hardware 
enforces them for manual external flashes.


Your idea isn't a free platform, it isn't owner controlled because you 
can't modify it - you can only be on the outside looking in.


--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] call on AMD to release src+specs+datasheets for ryzen

[Nico Huber]

On 04.03.2017 02:57, taii...@gmx.com wrote:
> Of course they also must release the signing keys as well afaik, or we
> would be stuck at a tivo style not really open source impasse.
> Nobody has mentioned this fact in that thread.

Please don't ask for that.

If somebody put a signature verification for his firmware in place, you
should first discuss the reasons and alternatives (for the particular
design in question). Sure there are alternatives to signature verifi-
cations to put some trust in hardware (like ROMs or the RO partitions
in cros devices). But removing the security checks from hardware who's
trust is designed around these checks? You'd likely end up with a sys-
tem where you have to check the flash contents with external hardware
before every boot (if it can be tampered with from the running system).

Of course you can ask for alternatives in new designs.

For yet released platforms, however, it's more feasible to ask for docu-
mentation, reproducible binaries and signatures (e.g. for fixes / reim-
plementations).

Nico


-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Reminder: The maiing list vs forum poll closes in just under 24 hours.

[David Hendricks]

On Fri, Mar 3, 2017 at 2:38 PM,  wrote:

> I would also really prefer a non-google poll.
> Taiidan wrote "I also do not like contributing to machine learning or
> advertising databases."
>
> You wrote "If people want to just email me responses, I can fill them into
> the form on their behalf."
>
> Thats exactly what he didnt want. He didnt want to feed skynet. Of course
> he also didnt want that you feed it for him with the data he provide to
> anyone.
>

I hate to sound like a jerk, but your opinions about coreboot's forum have
absolutely zero value to any prospective advertiser. If this subject is
important to you at all I suggest setting your ego aside and doing the poll
Martin set up. Then you can get back to moving markets with your brilliant
insights on other matters.
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot