[LEDE-DEV] [PATCH] firmware-utils: tplink-safeloader: keep per-device info on trailing char

[Rafał Miłecki]

From: Rafał Miłecki 

Recent refactoring introduced a regression. It ignored second argument
of make_support_list function which was originally true for C2600. The
new generic build_image function always passes false.

This patch allows specifying trailing char in a device specific info. It
also switches Archer C9 to the \0 char to make it compliant with vendor
images.

I verified generated images to be binary identical to the ones that
were created before whole refactoring.

Reported-by: Jo-Philipp Wich 
Fixes: fd924d2068f ("firmware-utils: tplink-safeloader: use one function for 
generating images")
Signed-off-by: Rafał Miłecki 
---
 tools/firmware-utils/src/tplink-safeloader.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/tools/firmware-utils/src/tplink-safeloader.c 
b/tools/firmware-utils/src/tplink-safeloader.c
index cefb071..2e8da8f 100644
--- a/tools/firmware-utils/src/tplink-safeloader.c
+++ b/tools/firmware-utils/src/tplink-safeloader.c
@@ -70,6 +70,7 @@ struct flash_partition_entry {
 struct device_info {
const char *vendor;
const char *support_list;
+   char support_trail;
const struct flash_partition_entry *partitions;
void *(*generate_sysupgrade_image)(const struct flash_partition_entry 
*flash_parts, const struct image_partition_entry *image_parts, size_t *len);
 };
@@ -347,14 +348,14 @@ static struct image_partition_entry 
make_soft_version(uint32_t rev) {
 }
 
 /** Generates the support-list partition */
-static struct image_partition_entry make_support_list(const char 
*support_list, bool trailzero) {
-   size_t len = strlen(support_list);
+static struct image_partition_entry make_support_list(struct device_info 
*info) {
+   size_t len = strlen(info->support_list);
struct image_partition_entry entry = 
alloc_image_partition("support-list", len + 9);
 
put32(entry.data, len);
memset(entry.data+4, 0, 4);
-   memcpy(entry.data+8, support_list, len);
-   entry.data[len+8] = trailzero ? '\x00' : '\xff';
+   memcpy(entry.data+8, info->support_list, len);
+   entry.data[len+8] = info->support_trail;
 
return entry;
 }
@@ -609,6 +610,7 @@ static void *generate_sysupgrade_image_eap120(const struct 
flash_partition_entry
 struct device_info cpe210_info = {
.vendor = cpe510_vendor,
.support_list = cpe210_support_list,
+   .support_trail = '\xff',
.partitions = cpe510_partitions,
.generate_sysupgrade_image = _sysupgrade_image,
 };
@@ -616,6 +618,7 @@ struct device_info cpe210_info = {
 struct device_info cpe510_info = {
.vendor = cpe510_vendor,
.support_list = cpe510_support_list,
+   .support_trail = '\xff',
.partitions = cpe510_partitions,
.generate_sysupgrade_image = _sysupgrade_image,
 };
@@ -623,6 +626,7 @@ struct device_info cpe510_info = {
 struct device_info c2600_info = {
.vendor = c2600_vendor,
.support_list = c2600_support_list,
+   .support_trail = '\x00',
.partitions = c2600_partitions,
.generate_sysupgrade_image = _sysupgrade_image_c2600,
 };
@@ -630,12 +634,14 @@ struct device_info c2600_info = {
 struct device_info e9_info = {
.vendor = c2600_vendor,
.support_list = c9_support_list,
+   .support_trail = '\x00',
.partitions = c5_partitions,
 };
 
 struct device_info eap120_info = {
.vendor = eap120_vendor,
.support_list = eap120_support_list,
+   .support_trail = '\xff',
.partitions = eap120_partitions,
.generate_sysupgrade_image = _sysupgrade_image_eap120,
 };
@@ -651,7 +657,7 @@ static void build_image(const char *output,
 
parts[0] = make_partition_table(info->partitions);
parts[1] = make_soft_version(rev);
-   parts[2] = make_support_list(info->support_list, false);
+   parts[2] = make_support_list(info);
parts[3] = read_file("os-image", kernel_image, false);
parts[4] = read_file("file-system", rootfs_image, add_jffs2_eof);
 
-- 
2.10.1


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] firmware-utils: replace md5 code with Alexander Peslyak's implementation

[Rafał Miłecki]

From: Rafał Miłecki 

Our current implementation is pretty old and uses some pre-standard/old
ANSI C style that triggers warnings like:
warning: call to function 'MD5_Init' without a real prototype 
[-Wunprototyped-calls]

This is caused by declarations specified in a following way:
src/md5.h:60:6: note: 'MD5_Init' was declared here
 void MD5_Init ();

Having these warnings makes it harded to notice real problems. We could
try hiding them but it makes more sense to just use a cleaner code.
Another tiny gain from this switch is slightly reduced binary size, on
x86_64 tplink-safeloader's size 48104 became 48003.

The new code in public domain, uses "heavily cut-down BSD license".

Signed-off-by: Rafał Miłecki 
---
 tools/firmware-utils/src/md5.c | 551 -
 tools/firmware-utils/src/md5.h |  92 +++
 2 files changed, 306 insertions(+), 337 deletions(-)

diff --git a/tools/firmware-utils/src/md5.c b/tools/firmware-utils/src/md5.c
index 2039760..52d96ac 100644
--- a/tools/firmware-utils/src/md5.c
+++ b/tools/firmware-utils/src/md5.c
@@ -1,307 +1,296 @@
-
-
 /*
- ***
- ** md5.c -- the source code for MD5 routines **
- ** RSA Data Security, Inc. MD5 Message-Digest Algorithm  **
- ** Created: 2/17/90 RLR  **
- ** Revised: 1/91 SRD,AJ,BSK,JT Reference C ver., 7/10 constant corr. **
- ***
+ * This is an OpenSSL-compatible implementation of the RSA Data Security, Inc.
+ * MD5 Message-Digest Algorithm (RFC 1321).
+ *
+ * Homepage:
+ * 
http://openwall.info/wiki/people/solar/software/public-domain-source-code/md5
+ *
+ * Author:
+ * Alexander Peslyak, better known as Solar Designer 
+ *
+ * This software was written by Alexander Peslyak in 2001.  No copyright is
+ * claimed, and the software is hereby placed in the public domain.
+ * In case this attempt to disclaim copyright and place the software in the
+ * public domain is deemed null and void, then the software is
+ * Copyright (c) 2001 Alexander Peslyak and it is hereby released to the
+ * general public under the following terms:
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted.
+ *
+ * There's ABSOLUTELY NO WARRANTY, express or implied.
+ *
+ * (This is a heavily cut-down "BSD license".)
+ *
+ * This differs from Colin Plumb's older public domain implementation in that
+ * no exactly 32-bit integer data type is required (any 32-bit or wider
+ * unsigned integer data type will do), there's no compile-time endianness
+ * configuration, and the function prototypes match OpenSSL's.  No code from
+ * Colin Plumb's implementation has been reused; this comment merely compares
+ * the properties of the two independent implementations.
+ *
+ * The primary goals of this implementation are portability and ease of use.
+ * It is meant to be fast, but not as fast as possible.  Some known
+ * optimizations are not included to reduce source code size and avoid
+ * compile-time configuration.
  */
 
-/*
- ***
- ** Copyright (C) 1990, RSA Data Security, Inc. All rights reserved.  **
- **   **
- ** License to copy and use this software is granted provided that**
- ** it is identified as the "RSA Data Security, Inc. MD5 Message- **
- ** Digest Algorithm" in all material mentioning or referencing this  **
- ** software or this function.**
- **   **
- ** License is also granted to make and use derivative works  **
- ** provided that such works are identified as "derived from the RSA  **
- ** Data Security, Inc. MD5 Message-Digest Algorithm" in all  **
- ** material mentioning or referencing the derived work.  **
- **   **
- ** RSA Data Security, Inc. makes no representations concerning   **
- ** either the merchantability of this software or the suitability**
- ** of this software for any particular purpose.  It is provided "as  **
- ** is" without express or implied warranty of any kind.  **
- **   **
- ** These notices must be retained in any copies of any part of this  **
- ** documentation and/or software.**
- ***
- */
+#ifndef HAVE_OPENSSL
 
 #include 
+
 #include "md5.h"
 
 /*
- ***
- **  Message-digest routines: 

Re: [LEDE-DEV] Release Preparation Questions

[Hannu Nyman]

On 19.11.2016 19:42, Jo-Philipp Wich wrote:

> $version = the base version number, e.g. 16.11 - this is what I'd like to 
be the main identifier
> $nickname = the symbolic name for a release branch, e.g. "Rolling Rabbit" 
- due to its arbitrary nature I do not want it to be part of directories or 
branch names
> $buildno = the number of the build produced by the build cluster dedicated 
to building the 16.11 base version, see e.g. the "buildnumber" property at [1]


Sounds good. Just keep the same terminology everywhere;-)

> > - branch builds before release:
> That should be versioned like $version+git$shorthash, e.g. 
"16.11+git6b40471".

> > - branch builds after a release:
> Assuming that for each released build we produce a tag then we would use 
the tag as designation plus the current hash, e.g. "16.11.1+git6b40471" or we 
can alternatively use the logic used for master and use the last tag as 
version number and count the number of commits since it, e.g. 16.11.1+r5"


One comment to both of those: commit hash is not incremental, so the "+r5" 
approach is better. Or even "+r5-+git6b40471".


You might also consider something similar as the LuCI "timestamp of last 
commit + hash" approach.
Example: "Master (git-16.324.51057-1c27f6b)" and "for-15.05 branch 
(git-16.043.44305-e2f9172)"

E.g. 16.11-16.324.51057-1c27f6b


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Release Preparation Questions

[Jo-Philipp Wich]

Some other consideration when thinking about tags:

Ideally we should rewrite the feeds.conf.default in the repository to
pin down the specific revisions used for the feeds which means that we
should likely produce automatic commits + automatic tags prior to
issuing the binary build.

This can happen in the form of a script which prepares the repo,
commits, pushes and finally triggers the buildbot.

~ Jo

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Release Preparation Questions

[Jo-Philipp Wich]

Hi David,

> does it really make sense to make a branch instead of just tagging
> commits? Is there really an expectation that there will be different
> changes in a release branch vs the mainline (especially for feeds, I can
> see an argument for the lede source in that you may backport some fixes
> into a release branch)

yes - I do expect that we will cherry pick changes from master into the
release branch (think OpenSSL updates) and maybe even back port smaller
changes and features.

> Other than this, it looks reasonable.

Thanks for the feedback.

~ Jo

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Release Preparation Questions

[Jo-Philipp Wich]

Hi Luiz,

> We need both: branch for the new release and tag the released commit
> and each subrelease (ex: x.y.2)

as mentioned in my other mail to Hannu we can automatically emit tags
for builds we publish but keep in mind that this will likely only work
for the base repository and not for the external feed repos.

~ Jo

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Release Preparation Questions

[Jo-Philipp Wich]

Hi Hannu,

sorry that some things where confusing, the mail was written in a hurry.

> I would prefer to have clear branches like "lede-16.11" for all the
> repos. Tags will not be sufficient when updates are made to the packages
> after the release and people compile new builds.

I too think that branches are more worthwhile since there is almost
never a good reason to rebuild an old version but we can automatically
create tags (even signed ones) in the form "lede-$version.$buildno" for
each source revision that got compiled by the release build farm so we'd
have tags in the form "lede-16.11.0", "lede-16.11.1" etc.

> Based on the above quotes from your message, I am still not quite sure
> what would be $version.  ("16.11", "Reboot Rabbit" or something else?

$version  = the base version number, e.g. 16.11 - this is what I'd like
to be the main identifier

$nickname = the symbolic name for a release branch, e.g.
"Rolling Rabbit" - due to its arbitrary nature I do not want
it to be part of directories or branch names

$buildno  = the number of the build  produced by the build cluster
dedicated to building the 16.11 base version, see e.g.
the "buildnumber" property at [1]

> The only input for your script are "release number" and "code name", 
> but following sentences contain also "version number", "nickname",
> "$version". And then for images also "version number" like x.y.z and
> "buildno" z of that x.y.z.

To clarify: "release number" = $version, "code name" = "nick name".
Build number is a dynamic property specific to the build cluster.

> [...] there are at least three different kind of branch builds, [...]
> 
> - branch builds before release: Branch codename designation, release
> branch number is known but no release yet, source commit/revision
> needed, (no branch opkg repo yet, so either no downloads or from
> snapshot repo if still compatible)

That should be versioned like $version+git$shorthash, e.g.
"16.11+git6b40471". Assuming a branch naming of "lede-xx.yy" it would be
something like:

  echo "`echo $branchname | cut -d- -f2`+git`git log --format=%h -1`"

> - branch release builds: Branch codename designation, official release
> number, source revision, opkg download from release repo

When one builds exactly a tag, it would be simply used as version, e.g.
16.11.1 - the buildbots can override it locally since they likely
produce the build before they tag the repo (to ensure successful building).

Assuming tags in the form "lede-xx.yy.buildno" it would be:

  echo $tagname | cut -d- -f2

> - branch builds after a release: Branch codename designation, last
> release number known + changes after it, source revision, opkg download
> from last release repo

Assuming that for each released build we produce a tag then we would use
the tag as designation plus the current hash, e.g. "16.11.1+git6b40471"
or we can alternatively use the logic used for master and use the last
tag as version number and count the number of commits since it, e.g.
16.11.1+r5"

> So please consider that your script produces sensible config values at
> the source repo for all the cases.

I think the approaches mentioned above should cover these cases.

> Ps. I still hate how config options and include/version.mk mix
> CONFIG_VERSION_NUMBER vs. REVISION/commit, CONFIG_VERSION_NICK option
> vs. hardcoded RELEASE definition, and again CONFIG_VERSION_NUMBER vs.
> "HEAD" for VERSION_CODE.  When looking at the release script, you might
> also consider if the config logic there needs some straightening.

Yes, we definitely need to untangle it, that is why I am seeking input.

~ Jo

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Release Preparation Questions

[Hannu Nyman]

I like your release approach in general.

I would prefer to have clear branches like "lede-16.11" for all the repos. 
Tags will not be sufficient when updates are made to the packages after the 
release and people compile new builds. (case for branch arises when a package 
has after a release first a major version bump e.g. 3.2-->4.0 and then a bit 
later a security fix 3.2.1 for the 3.2 in the release.)


And e.g. Openwrt uses nickname & version number confusingly: main firmware 
download is from "chaos_calmer" download directory and source branch, while 
feed source branches are "for-15.05".


Just make sure that you can keep the terminology clear during the discussion. 
I am raising this up now, because include/version.mk logic can be pretty 
confusing and your message leaves some things up.


Jo-Philipp Wich wrote at Sat Nov 19 06:20:07 PST 2016:
> ... just two arguments: a release number and a code name.
> ... the version number (or the nickname) alone.
> ... name it "lede-$version"
> ... shall have a version number X.Y.Z where X is the year of release, Y 
the month and Z the build number produced by buildbot
> ... 
http://downloads.lede-project.org/$version/targets/ar71xx/generic/packages/$buildno


Based on the above quotes from your message, I am still not quite sure what 
would be $version.  ("16.11", "Reboot Rabbit" or something else?


The only input for your script are "release number" and "code name",  but 
following sentences contain also "version number", "nickname", "$version". 
And then for images also "version number" like x.y.z and "buildno" z of that 
x.y.z.


I wrote earlier in 
http://lists.infradead.org/pipermail/lede-dev/2016-May/000271.html that there 
are at least three different kind of branch builds, as people also compile 
from branches (possibly already before the release during rc phase, plus 
after the release):


- branch builds before release: Branch codename designation, release branch 
number is known but no release yet, source commit/revision needed, (no branch 
opkg repo yet, so either no downloads or from snapshot repo if still compatible)


- branch release builds: Branch codename designation, official release 
number, source revision, opkg download from release repo


- branch builds after a release: Branch codename designation, last release 
number known + changes after it, source revision, opkg download from last 
release repo


So please consider that your script produces sensible config values at the 
source repo for all the cases.


Ps. I still hate how config options and include/version.mk mix 
CONFIG_VERSION_NUMBER vs. REVISION/commit, CONFIG_VERSION_NICK option vs. 
hardcoded RELEASE definition, and again CONFIG_VERSION_NUMBER vs. "HEAD" for 
VERSION_CODE.  When looking at the release script, you might also consider if 
the config logic there needs some straightening.



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Release Preparation Questions

[Luiz Angelo Daros de Luca]

We need both: branch for the new release and tag the released commit
and each subrelease (ex: x.y.2)

---
 Luiz Angelo Daros de Luca, Me.
luizl...@gmail.com

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Release Preparation Questions

[David Lang]

On Sat, 19 Nov 2016, Jo-Philipp Wich wrote:


Hi all,

I am currently on working on automating the required steps to cut a
proper release - in order to make this process as standardized and
repeatable as possible, I intend to script any required steps to avoid
the need for manual setup tasks as much as possible.

Ideally I want to reach a point where one runs a "make_release.sh" with
just two arguments: a release number and a code name.

In order to achieve that goal, we must ensure that any related resources
like download URLs, Git repositories etc. are using predictable names
which can be constructed from the version number (or the nickname) alone.

Below is a list of things I'd propose for automating release cutting,
please let me know if you agree or think otherwise.


REPOSITORY PREPARATION

1) Branch "source.git" and name it "lede-$version"

2) In the used package feeds, branch "lede-$version" and use it


does it really make sense to make a branch instead of just tagging commits? Is 
there really an expectation that there will be different changes in a release 
branch vs the mainline (especially for feeds, I can see an argument for the 
lede source in that you may backport some fixes into a release branch)


Other than this, it looks reasonable.

David Lang

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Release Preparation Questions

[Jo-Philipp Wich]

Hi all,

I am currently on working on automating the required steps to cut a
proper release - in order to make this process as standardized and
repeatable as possible, I intend to script any required steps to avoid
the need for manual setup tasks as much as possible.

Ideally I want to reach a point where one runs a "make_release.sh" with
just two arguments: a release number and a code name.

In order to achieve that goal, we must ensure that any related resources
like download URLs, Git repositories etc. are using predictable names
which can be constructed from the version number (or the nickname) alone.

Below is a list of things I'd propose for automating release cutting,
please let me know if you agree or think otherwise.


REPOSITORY PREPARATION

1) Branch "source.git" and name it "lede-$version"

2) In the used package feeds, branch "lede-$version" and use it

3) Use http://downloads.lede-project.org/$version/ as base
   download URL

4) In the "lede-$version" branch, adjust
   package/base-files/image-config.in to have proper defaults for
   CONFIG_VERSION_NICK, CONFIG_VERSION_NUMBER and CONFIG_VERSION_REPO,
   also default CONFIG_VERSIONOPT and CONFIG_VERSION_FILENAMES to y

VERSIONING

1) Images shall have a version number X.Y.Z where X is the year of
   release, Y the month and Z the build number produced by buildbot

2) The nonshared base repository holding kmods will be copied for each
   consecutive build, so there will be a

http://downloads.lede-project.org/$version/targets/ar71xx/generic/packages/$buildno
   for each build in order to ensure kmod compatibility even for older
   installed images

3) All other, sharable repositories will remain at the base version, eg.
   http://downloads.lede-project.org/$version/packages/mips_24kc/base to
   let older installed images benefit from updated packages

SIGNING

1) We generate a new GnuPG key pair per release and cross-sign that
   with multiple developer keys listed at
   https://www.lede-project.org/signatures.html

2) We generate a new usign/signify key pair per release and use that to
   sign the package lists - NOTE: we currently lack any support for
   cross-signing usign signatures so we need to figure out a solution
   for that

If no one objects to this I'll start implementing the points above in
the form of a series of release scripts which we can then use bootstrap
the release process.

Regards,
Jo

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] package/boot/uboot-envtools: add 'dockstar' for kirkwood

[p . wassi]

From: Paul Wassi 

Add board 'dockstar' to known fw_env-configurations.

Signed-off-by: Paul Wassi 
---
In order to get fw_printenv / fw_setenv working out-of-the-box on
a dockstar, the /etc/fw_env.config file is needed. This file is usually
created by uci-defaults/30_uboot-envtools but it currently has no idea
what to do with a dockstar.

 package/boot/uboot-envtools/files/kirkwood |1 +
 1 file changed, 1 insertion(+)

diff --git a/package/boot/uboot-envtools/files/kirkwood 
b/package/boot/uboot-envtools/files/kirkwood
--- a/package/boot/uboot-envtools/files/kirkwood
+++ b/package/boot/uboot-envtools/files/kirkwood
@@ -14,6 +14,7 @@ touch /etc/config/ubootenv
 board=$(kirkwood_board_name)
 
 case "$board" in
+"dockstar" | \
 "guruplug-server-plus" | \
 "ib62x0" | \
 "linksys-viper" | \

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev