From: Alessandro GARDICH <gremlin@gremlin.it>
To: openembedded-devel@openembedded.org
Subject: Re: checksums situation
Date: Sat, 28 Feb 2009 10:57:07 +0100 [thread overview]
Message-ID: <49A90A73.90109@gremlin.it> (raw)
In-Reply-To: <49A69032.9050505@opensimpad.org>
Bernhard Guillon wrote:
> Tom Rini wrote:
>> This is one of my points. People think we have security from our
>> current checksum list, but we do not.
>>
>>
> Then we have to make clear that the checksums are for integrity only and
> not for security.
> It is impossible for us to do security. E.g. most sourceforge projects
> do not sign their packages. We would need to review the source of every
> package to see if it does stuff it should not do. We would also need to
> track security updates for packages - which we should do anyway.
>
> Best regards
> Bernhard Guillon
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Sincerely I don't feel the need of "security" in OE but that is.
In my opinion the checking of the sources is a feature we can have but
for sure not in a global checksum.ini file, it's unmanageable.
Every recipe, in which is defined a source can have a checksum, as
someone else proposed is a better solution.
Talking about security in a strict way, check the sources have in my
opinion no sense, an "evil" recipe could fetch a well signed source of
ssh (as example) and apply a patch to add a back door.
Checking can be useful but not for security reason, at most just to be
sure the source is what expect to be.
How checksum behave is source is a latest revision of a VCS ?
Other point, I completely dislike the current behaviour : if a source
haven't a checksum fail do build. No please ... the default could be a
warning not a fail!
I'm sure 90% or OE users got a failure, ask for help and now have
OE_STRICT_CHECKSUMS = "" in their local.conf ... have it sense ???
In my opinion the default behaviour have to be a warning, for who is
sensible to a (false) security they can enforce the behaviour (suck as
-Werror for gcc) but no more.
A warning at the end of bitbake build could also be useful, something
like "your final image contain non checked sources", but not a FAIL!
Last but more important : why the hell this feature is in the default
dev branch ??? why wasn't created a "checksum" branch to test it !!!
One thing make OE UNUSABLE for day to day work is the BAD behaviour :
- think a feature
- start (but not finish) to implement it
- push
- make dev branch fail to build
- start to correct/finish the feature
damn, we got git to be easy to branch to test new features!!!
--
/-------------------------------------------------------------\
| Alessandro Gardich : gremlin#gremlin!it |
>-------------------------------------------------------------<
| I never saw a wild thing sorry for itself. |
| A small bird will drop frozen dead from a bough |
| without ever having felt sorry for itself. |
\-------------------------------------------------------------/
next prev parent reply other threads:[~2009-02-28 10:03 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-13 16:28 checksums situation Marcin Juszkiewicz
2009-02-13 17:08 ` Otavio Salvador
2009-02-13 17:39 ` Ihar Hrachyshka
2009-02-13 18:37 ` Otavio Salvador
2009-02-13 19:35 ` Leon Woestenberg
2010-02-12 18:45 ` mike
2009-02-13 19:41 ` John Willis
2009-02-15 10:04 ` Phil Blundell
2009-02-15 18:32 ` Otavio Salvador
2009-02-13 17:09 ` Tom Rini
2009-02-13 17:28 ` Andrea Adami
2009-02-13 17:34 ` Andrea Adami
2009-02-13 18:02 ` Koen Kooi
2009-02-14 14:51 ` Yuri Bushmelev
2009-02-24 6:46 ` Tom Rini
2009-02-24 6:51 ` Tom Rini
2009-02-24 8:49 ` Marcin Juszkiewicz
2009-02-24 15:02 ` Tom Rini
2009-02-24 16:13 ` Michael 'Mickey' Lauer
2009-02-24 16:25 ` Angus Ainslie
2009-02-24 16:37 ` Tom Rini
2009-02-24 16:28 ` Philip Balister
2009-02-24 16:36 ` Tom Rini
2009-02-24 22:10 ` GNUtoo
2009-02-24 22:17 ` Tom Rini
2009-02-24 22:29 ` Phil Blundell
2009-02-24 22:42 ` GNUtoo
2009-02-25 9:09 ` Richard Purdie
2009-02-25 23:04 ` Denys Dmytriyenko
2009-02-26 13:28 ` Richard Purdie
2009-02-27 0:20 ` Otavio Salvador
2009-02-24 18:01 ` Otavio Salvador
2009-02-24 18:36 ` Ihar Hrachyshka
2009-02-24 18:50 ` Tom Rini
2009-02-24 22:20 ` GNUtoo
2009-02-25 2:01 ` Otavio Salvador
2009-02-25 2:25 ` Tom Rini
2009-02-25 9:01 ` Richard Purdie
2009-02-25 21:27 ` Vitus Jensen
2009-02-25 21:35 ` Tom Rini
2009-02-25 22:04 ` Vitus Jensen
2009-02-26 8:10 ` Koen Kooi
2009-02-26 12:50 ` Bernhard Guillon
2009-02-28 9:57 ` Alessandro GARDICH [this message]
2009-02-28 10:45 ` Koen Kooi
2009-02-28 10:51 ` Alessandro GARDICH
2009-02-28 13:12 ` Philip Balister
2009-02-24 20:29 ` Bernhard Guillon
2009-02-24 22:45 ` GNUtoo
2009-02-25 9:16 ` Koen Kooi
-- strict thread matches above, loose matches on Subject: below --
2009-02-24 20:00 Frans Meulenbroeks
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49A90A73.90109@gremlin.it \
--to=gremlin@gremlin.it \
--cc=openembedded-devel@lists.openembedded.org \
--cc=openembedded-devel@openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.