Re: [OE-core] OEDAM @ SCaLE 2019

2018-11-02 Thread Sean Hudson 
On 11/2/18 10:57 AM, akuster808 wrote:
> Morning Trevor,
> 
> On 11/1/18 7:27 PM, Trevor Woerner wrote:
>> Hi Jon,
>>
>> On Thu, Nov 1, 2018 at 3:56 PM Jon Mason > > wrote:
>>
>> I am planning on being at SCaLE (assuming the OEDEM happens there).
>>
>> Many corporate travel budgets are tied to presenting at conferences.
>> So, if we could somehow get a track there (which might be too late in
>> the game to do now), then we might be able to get enough people
>> present to make it happen and pull in others whose budget is more
>> flexible.
>>
>>
>> As it turns out, I'll be organising the YP/OE Miniconf that will most
>> likely be run on the Sunday. I was going to send out a separate email
>> discussing the Miniconf, but I guess now is as good a time as any :-)
> 
> 
> I would like a some clarification. As fas as the OE Board knows, we had
> one room available on Sunday. Is this the same room or did you find some
> other space at the venue? I am a bit confused about the messaging. The
> subject and Jon's statement are all about OEDaM but your addition to
> this tread is about a Miniconf. Is the Miniconf a separate thing?
> 
>>
>> While it's true that the CFP has closed for SCaLE, I plan to open my
>> own CFP specifically for the Miniconf, and I don't plan to close it
>> until closer to the conference itself. I want to encourage people to
>> give talks about current things, as such, having a CFP close this
>> early wouldn't do.
>>
>> We haven't decided on a format for the Miniconf, exactly, if we have
>> traditional talks, we'll have 6 sessions (2 before lunch, 4 after).
>> But depending on interest and what sort of proposals we get, we might
>> do some longer, some shorter talks.
> 
> 
> May I ask who "We" are? AFAIK, Behan and Tom are doing a *-ale tracks at
> Scale.
> 
> 


Trevor,

  The OpenEmbedded board had a quick discussion and would like to share
a few things.
  First, the board fully supports any OpenEmbedded member organizing
community events.
  Second, thank you for stepping up to organize such an event.  We
greatly appreciate it and will support you as best we can.

  Third, the desire for user-centric events or a separate conference
entirely has been discussed at several of the recent developer meetings,
while at the same time, we've seen a growing number of users attending
these meetings "just to observe".  It sounds like the event that you are
starting to organize at SCaLE presents the perfect opportunity to start
creating such a user-centric meeting.

 Lastly, as was brought up at the meeting in Edinburgh, this is all
occurring *very* late for conference planning, which adds greatly to
everyone's stress and angst.

  With that said, the board does have a concern, a request, and a
suggestion. (triple threat!)

  The concern arises from the history associated with the OEDEM and
OEDAM names/meetings.  Specifically, we are concerned about possible
confusion that may arise from overusing those terms.  FWIW, members
expressed this at the last several developer meetings publicly and have
also expressed reservations to board members privately. For many,
employers will only pay for them to go to a single "meeting" a year.
This means we need to make it easy for users, developers, and their
employers to know what type of meeting is being held.

  So, we request that you call the event that you are organizing an
OpenEmbedded User Summit, or something similar.  We think this will help
clarify things and it also preserves the use of the "official",
OpenEmbedded Developer Meetings terms, e.g. OEDEM or OEDAM, for the OE
developers.

  Recognizing that we are scrambling to get things organized at the last
minute, we further suggest that we put together a quick verbal
discussion with all the necessary folks present.  ATM, that appears to
be you, Tom K, Behan, and the OE board.

-- 
Sean
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [Openembedded-architecture] OE-Core/Yocto Project's first CVE (CVE-2017-9731)

2017-06-20 Thread Sean Hudson 
On 2017-06-20 04:30 AM, Paul Eggleton wrote:
> On Monday, 19 June 2017 5:31:10 PM CEST Sean Hudson wrote:
>> On 2017-06-19 09:05 AM, Mark Hatle wrote:
>>> It would be reasonable to write up a 'best practices' type document. 
>>> Explaining that simply due to the nature of building many of these things
>>> will be 'leaked' and where some of them are leaked through.  (Package
>>> generation, compilation, etc for instance.)
>>
>> That sounds reasonable, although, TBH, if someone is adding credentials
>> to their SRC_URIs, I would expect that a best practice would be ignored.
>>  Perhaps adding a detection routine that emitted a warning during
>> parsing for credentials in the SRC_URI might be warranted?  Thoughts?
> 
> This might be useful yes. I think the stumbling block is that at the moment we
> would have to have it off by default and then the user is almost certainly not
> going to know to turn it on. Perhaps this is another thing that we might 
> check 
> in a "production" vs. "development" mode where the user can easily switch to
> the former to enable a set of more stringent checks.

I'm not sure I follow.  What would prevent us from turning on a warning
that detected credentials in a SRC_URI by default?  Even with Richard's
change to prevent the information from propagating into the .ipk, it
seems useful to notify the user.  Personally, I'd like to know if one of
the recipes I'm using has such information in it regardless of whether
I'm generating a development or a production image.


-- 
Sean



signature.asc
Description: OpenPGP digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [Openembedded-architecture] OE-Core/Yocto Project's first CVE (CVE-2017-9731)

2017-06-19 Thread Sean Hudson 
On 2017-06-19 09:05 AM, Mark Hatle wrote:
> On 6/19/17 8:20 AM, Philip Balister wrote:
>> On 06/19/2017 06:38 AM, Richard Purdie wrote:
>>> I suspect this has been missed by some people so I want to spell it
>>> out. We have our first CVE in OE-Core itself.
>>>
>>> The issue is limited to binary ipks potentially exposing sensitive
>>> information through the "Source:" field which contained the full
>>> SRC_URI. Those urls could potentially contain sensitive information
>>> about servers and credentials.
>>
>> So the issue is leaking credentials, not build system paths? I mention
>> this because we do leak build system paths into images in other places.
> 
> Build systems paths would be unrelated to this, assuming I understand it 
> properly.
> 
> Information leak of the build user, time of build, and build system paths can
> all occur.  (This is part of the overall binary reproducible stuff as well.)
> 
> When it comes to information leaks, specifically build system leaks.  As long 
> as
> they don't contain credential information then it is a point of mitigation vs 
> a
> 'bug' in my opinion.  We clearly want to move toward a binary reproducible 
> build
> -- doing so will further limit the leaks (or at least make them understood.)
> 
> For build user, hostname, directories and build time/date issues -- we've
> already mitigated many of them.  Directory structure was done when we started 
> to
> use the compilers path replacement operations.  (It's probably not 100%
> effective, but I'd say any items that are left are reasonable bug candidates.)
> We've also made passes to remove many of the other items, but I'd simply
> consider them regular bugs at this point...  but information leaks like this 
> are
> something people often don't think about and probably should be made aware of.
> 
> It would be reasonable to write up a 'best practices' type document.  
> Explaining
> that simply due to the nature of building many of these things will be 
> 'leaked'
> and where some of them are leaked through.  (Package generation, compilation,
> etc for instance.)

That sounds reasonable, although, TBH, if someone is adding credentials
to their SRC_URIs, I would expect that a best practice would be ignored.
 Perhaps adding a detection routine that emitted a warning during
parsing for credentials in the SRC_URI might be warranted?  Thoughts?

> 
> Controlling your 'production' build environment can mitigate many of the
> potential issues here.  By using non-confidential path names (i.e. don't 
> include
> confidential 'customer', code-name, etc in build paths), changing or otherwise
> managing the host name on your build system (i.e. instead of
> my-product.my-company.internal.com... something like 'build-1' as a hostname 
> can
> help hide many of these things.)  Using a 'build user' who doesn't have any
> network credentials, other then on the build system itself...
> 
> --Mark
> 
>> Philip
>>
>>
>>>
>>> After discussion, I ended up changing the field to contain the recipe
>>> filename (no path). There was talk of filtering the urls however if you
>>> try, it becomes clear that sensitive elements can remain and no
>>> solution is likely 100% effective. The other package backends don't do
>>> this at all so this brings ipk more into line with them. Simply
>>> clearing the field doesn't work with the current opkg-utils. It can be
>>> changed but the change becomes more invasive.
>>>
>>> This fix has been merged to master.
>>>
>>> I also did take the decision to backport this change back to
>>> pyro/morty/krogoth too. I appreciate this can cause some disruption to
>>> people who rely on SRC_URI being in the Source: field however I
>>> couldn't see any other realistic way forward.
>>>
>>> Cheers,
>>>
>>> Richard
>>> ___
>>> Openembedded-architecture mailing list
>>> openembedded-architect...@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>>>
>> ___
>> Openembedded-architecture mailing list
>> openembedded-architect...@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>>
> 
> ___
> Openembedded-architecture mailing list
> openembedded-architect...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
> 


-- 
Sean



signature.asc
Description: OpenPGP digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Bitbake shell wrapper script

2017-04-26 Thread Sean Hudson 
I created a bash wrapper script some time ago to help prevent host shell
contamination from OE environment vars and also to isolate the OE build
environment.  I know I've mentioned it to a few of you before, so, I've
finally posted it for folks to look at.  I don't claim that it's
completely tested for corner cases, so, as always, YMMV.  Take a look
and let me know what you think.

Source can be found here:
  https://github.com/MentorEmbedded/bbsh

-- 
Sean



signature.asc
Description: OpenPGP digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] OpenEmbedded 2017 General Meeting

2017-04-20 Thread Sean Hudson 
On 2017-04-19 03:48 PM, Sean Hudson wrote:
> The board would like to hold a general meeting with all members.  Under
> the new by-laws of the OpenEmbedded organization, we can meet
> electronically.  This will also fulfill the requirement for an annual,
> general meeting.
> 
> Planned Date/Time:
> Wednesday, May 3rd, at 8am US-CDT(UTC-06:00)/3pm CET(UTC+01:00)
> 
> Wiki page with full details, including teleconference information here:
> http://www.openembedded.org/wiki/2017_General_Meeting
> 
> Please take a moment to add your name to the list if you are planning to
> attend and any agenda items you would like to discuss.
> 

I found an updated list of access numbers that include several country
specific toll-free numbers for the teleconference.  I've updated the
wiki page with the details.  I also setup a #oe-meeting IRC channel that
we can use as a back channel before and during the meeting.

-- 
Sean



signature.asc
Description: OpenPGP digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe] OpenEmbedded 2017 General Meeting

2017-04-19 Thread Sean Hudson 
On 2017-04-19 06:10 PM, Trevor Woerner wrote:
> Could you please use
> https://www.timeanddate.com/worldclock/fixedform.html to specify the
> date/time?
> 

Never used it before.  Handy.

Here's a link to the time:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenEmbedded+2017+General+Meeting&iso=20170503T08&p1=24&ah=1

Here's a link to a countdown:  :)

https://www.timeanddate.com/countdown/generic?p0=24&iso=20170503T08&msg=OpenEmbedded%202017%20General%20Meeting

I'm adding both to the wiki as well.

-- 
Sean



signature.asc
Description: OpenPGP digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] OpenEmbedded 2017 General Meeting

2017-04-19 Thread Sean Hudson 
The board would like to hold a general meeting with all members.  Under
the new by-laws of the OpenEmbedded organization, we can meet
electronically.  This will also fulfill the requirement for an annual,
general meeting.

Planned Date/Time:
Wednesday, May 3rd, at 8am US-CDT(UTC-06:00)/3pm CET(UTC+01:00)

Wiki page with full details, including teleconference information here:
http://www.openembedded.org/wiki/2017_General_Meeting

Please take a moment to add your name to the list if you are planning to
attend and any agenda items you would like to discuss.

-- 
Sean



signature.asc
Description: OpenPGP digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] OEDEM Oct 9, after ELCE and Yocto Project Developer Day

2015-07-31 Thread Sean Hudson 
On 7/31/2015 4:56 PM, Philip Balister wrote:
> OpenEmbedded will hold a developer meeting Oct 9 after ELCE and YP dev
> day in Dublin.
> 
> This is a chance for developers and users of OpenEmbedded (The Yocto
> Project build system) to meet and discuss important project issues.
> Everyone is welcome to attend. We are planning on about 30 people so do
> not worry about taking space from someone important.
> 
> For people that have not attended one of these, we will collect items on
> the wiki and try to setup a rough agenda before the event. Please add
> your thoughts.
> 
> If you plan to attend, add your name here:
> 
> http://www.openembedded.org/wiki/OEDEM
> 
> Also, add items you would like to discuss. It would be great if we could
> get a good estimate so Jefro can make sure he reserves the correct
> amount of space. So if you are even thinking of attending add your name
> with (tentative) after it this weekend.
> 
> Thanks,
> 
> Philip
> 

Although it says it right at the top of the page on the link that Philip
provided, I want to highlight it on the list.  During this OEDEM, we
will also have the OE General Assembly, per the e.V. statues.  So, don't
forget to get your proxies in place ahead of time!

-- 
Sean
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/4] [V3]mesa: upgrade to 10.1.3

2014-05-27 Thread Sean Hudson 
On 05/22/2014 11:58 AM, Burton, Ross wrote:
> For these three patches:
> 
> On 22 May 2014 17:28, Valentin Popa  wrote:
>>>dri3proto: add it to oe-core
>>>libxshmfence: add it to oe-core
>>>eglinfo: patched to compile with mesa10+
> 
> Signed-off-by: Ross Burton 
> 
> Mesa needs more testing, but these pieces are good to merge.
> 
> Ross
> 

  I don't have a specific need to preserve MESA 9.x (that I know of
right now), but it seems like we might consider keeping it around a bit
longer in parallel with MESA 10.x and then formally deprecate it in the
next release.

Regards,
 Sean

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] New meta-amd mailing list announcement

2014-05-12 Thread Sean Hudson 
There is a new mailing list for AMD platform/board related patches and
discussion.
You can sign up here: https://lists.yoctoproject.org/listinfo/meta-amd

The meta-amd layer git repository is publicly available here:
git://git.yoctoproject.org/meta-amd
(cgit web interface here:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-amd/)

Please checkout the README at the top level for details on submitting
patches.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Recipes erroneously marked as "commercial"?

2014-05-06 Thread Sean Hudson 
On 05/06/2014 03:00 PM, Denys Dmytriyenko wrote:
> So, long time ago we had a short list of "commercial" packages in a global 
> variable COMMERCIAL_LICENSE:
>
> COMMERCIAL_LICENSE ?= "lame gst-fluendo-mp3 libmad mpeg2dec ffmpeg qmmp"
>
> Then, at some point, the packages that depend on commercial ones were added 
> to 
> the list, to allow wold builds to be successful:
>
> http://cgit.openembedded.org/openembedded-core/commit/?id=c69453fe94a649c518b0e6d79616f05579b864ce
>
> So, the list was appended with this:
>
> COMMERCIAL_LICENSE_DEPENDEES ?= "gst-plugins-ugly libomxil gst-openmax"
>
> Then, later on, the feature was changed from a global list to a per-recipe 
> flags:
>
> http://cgit.openembedded.org/openembedded-core/commit/?id=a2760661b8c7a4a1b6f2e556853b3a9ae38cbcb5
> http://cgit.openembedded.org/openembedded-core/commit/?id=43410523a07d9eb52a7d57ae3dc1cc320cbbc6f9
>
> And all those recipes got marked with LICENSE_FLAGS = "commercial" 
> automatically, even if they are not really commercial.
>
> The question is - should we clean those up now? I can send a quick patch, if 
> my understanding above is correct.
>
I encountered this issue recently and raised it in IRC.  As an
interested party, I'd love to see these updated.

  (Thanks Denys for sending it to the list so quickly.)
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] OE, the TSC and the future

2013-07-08 Thread Sean Hudson 

On 7/5/13 6:46 PM, Phil Blundell wrote:

On Tue, 2013-06-18 at 17:23 +0100, Richard Purdie wrote:

In brief summary the TSC has been doing two main things, acting as a
task force and also being able to make a decision when needed. The
latter has not happened much at all, the main work was as a task force
on various issues, firstly engaging with the Yocto Project and figuring
that out, more recently dealing with infrastructure issues and generally
ensuring the health of OE.

It's certainly true that most of the current TSC members have been doing
a fine job on the "task force" front and I think we'd all be glad to see
them continue with that.  What's rather less obvious to me is whether
they actually need to be an elected body in order to do so; any group of
individuals who wish to form a task force are obviously free and welcome
to do so at any time.

As you note, the requirement for the TSC to actually make decisions has
been minimal/nonexistent of late and, again, it's not totally obvious
that having an elected body of experts on perpetual standby just in case
a decision might be needed is entirely necessary.

In the many-layered world that we now inhabit, it seems reasonable to
let the individual layer maintainers (in consultation with their peers
when necessary) make the decisions that they think best for their own
trees.  Recent experience seems to suggest that, practically speaking,
this is already what's happening and when it comes to a contest of wills
the TSC have not shown any interest in overruling layer maintainers who
disagree with their stated position.

Plus, of course, we already have two bodies who are empowered by the OE
e.V. statutes to make decisions, namely the board and the GA.   Both of
these have wide discretion to do what they think best, and of course
they can convene a panel of expert advisers if they feel that any
particular issue needs specialist knowledge that they don't have.

So, all in all, I feel that we've come to the point where the TSC (as an
organisation) is no longer providing us with any particular benefits and
could be disbanded without causing any real hardship.  This would avoid
the administrative overhead of running elections for each of its seats,
which have recently been uncontested in any case, and would also avoid a
certain amount of potential ambiguity over where the TSC's jurisdiction
ends and the board's starts.


I believe that Phil Blundell raises a valid question about the continuing
need for the TSC. However, it seems to me that the need for a group to
arbitrate on technical matters is valuable enough, by itself, to keep 
the TSC.

This applies even if that function is utilized infrequently.

In considering the future of the TSC, I offer the opinion that in the 
future,

tactical concerns shouldn't be the primary business for the TSC. Rather, I'd
like to see the TSC become more strategically focused. In particular, 
I'd like
to have the TSC produce a vision for OE in the 2-3 year time frame. As 
another
OE board member, I support Phil Balister's offer to have the 
non-technical matters
fall to the board to handle, with the caveat that the TSC becomes more 
focused on

the long term evolution and improvement of OE as a whole

Regards,
 Sean
 
Sean Hudson | Embedded Linux Architect

Mentor Embedded™
Nucleus® | Linux® | Android™ | Services | UI | Multi-OS

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core