Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v3] ca-certificates: new package
Date: Sun, 12 Jan 2014 21:09:37 +0100	[thread overview]
Message-ID: <20140112200937.GC3374@free.fr> (raw)
In-Reply-To: <8738kt3t5f.fsf@dell.be.48ers.dk>

Peter, All,

On 2014-01-12 20:19 +0100, Peter Korsgaard spake thusly:
> >>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:
>  >> > I guess there's no point in adding such a check for git, svn and all
[--SNIP--]
>  > For a VCS, maybe the list of files and their respective contents are OK,
>  > but we can't say anything about the generated archive.
> 
> True. If we implement it like _LICENSE, we can probably just not add
> those tags for packages using git/hg/svn/..

I've already started implementing that, and it looks like we have a
problem.

The problem is that some packages have more than one download:
  - the tarball itself
  - optional patches, by way of PKG_PATCH
  - additional files, by way of PKG_EXTRA_DOWNLOADS

So, if we want to implement it at all, we have to provide the check for
those other downloads too. And a variable is not enough.

Another solution would be to annotate each file with its hash, someting
like:
    foo-1.2.3.patch:ABCDEF1234567890 bla.patch:ABCDEF1234567890 \
    file.bin:ABCDEF1234567890

This is ugly, and very convenient either.

An third alternative is to add a package/pkg/pkg.hash file, which
contains the list of files, and their hashes; in fact, the output of the
hash util we'd use:
    ABCDEF1234567890  foo-1.2.3.patch
    ABCDEF1234567890  bla.patch
    ABCDEF1234567890  file.bin

So, it indeed adds a third file to the existing pkg.mk and Config.in,
but it looks like it is the cleanest solution to me, and the one I've
started implementing.

Also, we'd have to settle for a hash function. md5 is outdated and
subject to attacks; sha1 is still current, but there are known potential
attacks; sha2/256 is still very strong for the foreseeable future;
sha2/512 seems like a bit overkill, although the time to hash is not
very different between sha2/256 and sha2/512.

This can be very easily changed, so I've settled for sha2/256 for now.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

  reply	other threads:[~2014-01-12 20:09 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-10 15:39 [Buildroot] [PATCH v3] ca-certificates: new package Martin Bark
2014-01-11 23:48 ` Yann E. MORIN
2014-01-12  8:38   ` Peter Korsgaard
2014-01-12 11:27     ` Yann E. MORIN
2014-01-12 18:23       ` Peter Korsgaard
2014-01-12 18:34         ` Yann E. MORIN
2014-01-12 19:19           ` Peter Korsgaard
2014-01-12 20:09             ` Yann E. MORIN [this message]
2014-01-12 20:32               ` Peter Korsgaard
2014-01-12 21:01                 ` Yann E. MORIN
2014-01-12 21:08                   ` Peter Korsgaard
2014-01-12 21:21               ` Bernd Kuhls
2014-01-12 21:38                 ` Yann E. MORIN
2014-01-14  7:13           ` Arnout Vandecappelle
2014-01-12 20:09 ` Peter Korsgaard
2014-01-12 20:39   ` Martin Bark

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=20140112200937.GC3374@free.fr \
    --to=yann.morin.1998@free.fr \
    --cc=buildroot@busybox.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox