[cip-dev] Was: Software updates comparison

[cip-dev] Was: Software updates comparison

[Stefano Babic]

Hi Daniel,

> Hi,
> 
> I have added a Software updates comparison report to our wiki:
> https://wiki.linuxfoundation.org/civilinfrastructureplatform/cip_comparison_report
> 
> This comparison is mostly based on other comparisons reports, experience from CIP members and from reading the documentation.
> 
> For this initial iteration we decided to prepare a prototype using SWUpdate+librsync (for the binary deltas) and ISAR. Having said that, the CIP Software updates workgroup is open to other methods and contributions (specially in the form of patches). Our aim is to provide guidance and reference code/metadata for CIP users to update their devices using existing OSS update tools.
> 
> If you think that information in the comparison is not accurate or you want to complement it please let me know.

Thanks for the document - I am mainly interested on the good and bad
points about SWpdate and I can put a couple of details:

Bad points

- depends on libubootenv which needs to be rebuilt for each target.

This was a well known issue and source of several conflicts in the past.
Thanks to a customer of mines, I have implemented a new libubootenv
library that is hardware independent and fixes this issue. Not only,
this could allow in future to extend it and introduce security features,
like signed environment:

	https://github.com/sbabic/libubootenv

The library must be explicitely activated in SWUpdate's configuration,
it will become the default in future.

- hard to manage updates from v1 to v5 directly

This is also a topic I had on my desk - as it is possible to read in
your comparison / research, this can be solved if SWUpdate and CASync
can be combined. But to make things correct, SWUpdate should well
integrate CASync and uses it as library - this requires some changes in
CASync, too. I had a draft design about this, but due to the complexity
/ effort, the project asking for delta-update decided in another
direction. There is currently no further work in SWUpdate in this direction.

Best regards,
Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

[cip-dev] Was: Software updates comparison

[Info]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Stefano Babic <sbabic@denx.de> wrote:
> Hi Daniel,
> 
> > Hi,
> > 
> > I have added a Software updates comparison report to our wiki:
> > https://wiki.linuxfoundation.org/civilinfrastructureplatform/cip_comparison_report

I actually find this comparison surprisingly lacking from a
security and methodology stand point given that its quite
limited, and leaves out other well know and not so well known. I
am sure we dont need to mention the likes of Balena and
Mender..... I was quite surprised to see RAUC, as it is not so
well known however... your missing ostree, tuf and uptane .. and
honestly from a security standpoint this combination far
surpasses any of the previously mentioned in methodology and
implementation. Along with OTA Community Edition, it is by far
the best solution, far more so then hawkbit, swupdate and TUF

https://uptane.github.io/
https://github.com/advancedtelematic/ota-community-edition
https://github.com/advancedtelematic/aktualizr

> > 
> > This comparison is mostly based on other comparisons reports, experience from CIP members and from reading the documentation.
> > 
> > For this initial iteration we decided to prepare a prototype using SWUpdate+librsync (for the binary deltas) and ISAR. Having said that, the CIP Software updates workgroup is open to other methods and contributions (specially in the form of patches). Our aim is to provide guidance and reference code/metadata for CIP users to update their devices using existing OSS update tools.
> > 
> > If you think that information in the comparison is not accurate or you want to complement it please let me know.
> 
> Thanks for the document - I am mainly interested on the good
> and bad points about SWpdate and I can put a couple of details:
> 
> Bad points
> 
> - depends on libubootenv which needs to be rebuilt for each target.
> 
> This was a well known issue and source of several conflicts in
> the past. Thanks to a customer of mines, I have implemented a
> new libubootenv library that is hardware independent and fixes
> this issue. Not only, this could allow in future to extend it
> and introduce security features, like signed environment:
> 
> 	https://github.com/sbabic/libubootenv
> 
> The library must be explicitely activated in SWUpdate's
> configuration, it will become the default in future.
> 
> - hard to manage updates from v1 to v5 directly
> 
> This is also a topic I had on my desk - as it is possible to
> read in your comparison / research, this can be solved if
> SWUpdate and CASync can be combined. But to make things
> correct, SWUpdate should well integrate CASync and uses it as
> library - this requires some changes in CASync, too. I had a
> draft design about this, but due to the complexity
> / effort, the project asking for delta-update decided in another
> direction. There is currently no further work in SWUpdate in
> this direction.
> 
> Best regards,
> Stefano
>

- -- 
Sent using Mailpile, Free Software from www.mailpile.is

-----BEGIN PGP SIGNATURE-----

iQGzBAEBCgAdFiEEu1jhkyGqo2gz54+mOQO0cdlUo7MFAlyzXdsACgkQOQO0cdlU
o7NWCQv+J7i7SevPTWa2qcIzQZzQEViXe9eATi+n68J3ZETC3Gqm0nFzzUPObryU
dOGbp8t5mf02RT8ppPLkCTA/sLxmVJOEBAzWErVA1y6KQzaTkmZe4y+iSrX0E87s
Fl8giVRiXT2cxq3s1uLhfo3X0GWT/DJqTHdNc8X8OFkoyYTzDh6HiYqWMungplyC
SQnzzfPGZkFECoaZUaepkzWvYILIJN7vCta5NeDKSTaYsbdyfpY9vDZRi7eCgmNw
WfxS4qcW4IEaNZ647AUa0LAYRhMJgMqOmUICuOuoyVd2nx7tU6ZtsQMTpD+2lu40
hcvu2Ew2Hcn/If1UhaWJL2sGlfRY4T8wVdz/UdP8bRK1cTqXEBKbexIPFmcOwhPM
wix0E8DbbhPoQR/tefJolnK7UPj5x7aoMsYWayvnE2VkKYhbGu3e5CaqElIakpdt
xZtiZUqvqHUrrhVhnIlUIfCA4nhMFY+0xTP13Gvgxl+4Ai75QN/Rtw0xFQxktjSI
AiCfvh8G
=ownp
-----END PGP SIGNATURE-----

[cip-dev] Was: Software updates comparison

[Scott V. Kamp]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Stefano Babic <sbabic@denx.de> wrote:
> Hi Daniel,
> 
> > Hi,
> > 
> > I have added a Software updates comparison report to our wiki:
> > https://wiki.linuxfoundation.org/civilinfrastructureplatform/cip_comparison_report


I actually find this comparison surprisingly lacking from a
security and methodology stand point given that its quite
limited, and leaves out other well know and not so well known. I
am sure we dont need to mention the likes of Balena and
Mender..... I was quite surprised to see RAUC, as it is not so
well known however... your missing ostree, tuf and uptane .. and
honestly from a security standpoint this combination far
surpasses any of the previously mentioned in methodology and
implementation. Along with OTA Community Edition, it is by far
the best solution, far more so then hawkbit, swupdate and TUF

https://uptane.github.io/
https://github.com/advancedtelematic/...
https://github.com/advancedtelematic/...


> > 
> > This comparison is mostly based on other comparisons reports, experience from CIP members and from reading the documentation.
> > 
> > For this initial iteration we decided to prepare a prototype using SWUpdate+librsync (for the binary deltas) and ISAR. Having said that, the CIP Software updates workgroup is open to other methods and contributions (specially in the form of patches). Our aim is to provide guidance and reference code/metadata for CIP users to update their devices using existing OSS update tools.
> > 
> > If you think that information in the comparison is not accurate or you want to complement it please let me know.
> 
> Thanks for the document - I am mainly interested on the good
> and bad points about SWpdate and I can put a couple of details:
> 
> Bad points
> 
> - depends on libubootenv which needs to be rebuilt for each target.
> 
> This was a well known issue and source of several conflicts in
> the past. Thanks to a customer of mines, I have implemented a
> new libubootenv library that is hardware independent and fixes
> this issue. Not only, this could allow in future to extend it
> and introduce security features, like signed environment:
> 
> 	https://github.com/sbabic/libubootenv
> 
> The library must be explicitely activated in SWUpdate's
> configuration, it will become the default in future.
> 
> - hard to manage updates from v1 to v5 directly
> 
> This is also a topic I had on my desk - as it is possible to
> read in your comparison / research, this can be solved if
> SWUpdate and CASync can be combined. But to make things
> correct, SWUpdate should well integrate CASync and uses it as
> library - this requires some changes in CASync, too. I had a
> draft design about this, but due to the complexity
> / effort, the project asking for delta-update decided in another
> direction. There is currently no further work in SWUpdate in
> this direction.
> 
> Best regards,
> Stefano
>

- -- 
Sent using Mailpile, Free Software from www.mailpile.is

-----BEGIN PGP SIGNATURE-----

iQGzBAEBCgAdFiEED83jmcaGxJZGGerGKdK9XRgP+iUFAlyz3o0ACgkQKdK9XRgP
+iVBZAv/a9kHLyHdZUbZA1EiJE0WaLwmmD+lp07A9s2cPfNTf5px/8DtbYPrLhm9
s+atSMbrWUl1R7v1hmZ6tPmZpXAOz+EJgknoRr40+FlBIgF/MZvnq29Zg91igKcG
ZEHJq1AJl68dzm5O70DGoMIrxZ/k2WAeElZ+JPR7aN7RiYCNm4qTwvt/QLpNwmuT
Hr+sDZvWbomGd/VwuXuttW6o/Lpq1al9GljmedBsycBcPCWkc6G7eupyoNSTNmli
jKvwlxx/5loapVDMuI+l2cQX6MVVTSrhqGxhB1w2SFmZBsWDgFV/snds9rK4Q6KE
SS4sLsM2PxrFK/fRFHHUzUPc4thmnRHOp0XOR3+qRen2MyVeQxJjlouTBn9nCSOy
wy5zh10QAMboC0H5HARnS4fWOrwpwEfFPX16s+uSMbF36JJMyqokk23Z5asxQTV8
+YBV9tJch1U311BUG4zS8yTKm1kRSDbGQs21V5xxPirKhsFTepwgLfwbTSK+cxjk
MyCZR5wM
=7PB7
-----END PGP SIGNATURE-----

[cip-dev] Was: Software updates comparison

[daniel.sangorrin at toshiba.co.jp]

Hi Stefano,

Thanks a lot for the clarifications. 
# Christian (Siemens) had already informed us about part of the progress.

> From: Stefano Babic <sbabic@denx.de>
[...]
> - depends on libubootenv which needs to be rebuilt for each target.
> 
> This was a well known issue and source of several conflicts in the past.
> Thanks to a customer of mines, I have implemented a new libubootenv
> library that is hardware independent and fixes this issue. Not only, this could
> allow in future to extend it and introduce security features, like signed
> environment:
> 
> 	https://github.com/sbabic/libubootenv
> 
> The library must be explicitely activated in SWUpdate's configuration, it will
> become the default in future.

Sounds great.
I think that SZ Lin (Moxa) was already preparing a Debian package.
If the new library is mature enough then we should enable it by default.
 
> - hard to manage updates from v1 to v5 directly
> 
> This is also a topic I had on my desk - as it is possible to read in your
> comparison / research, this can be solved if SWUpdate and CASync can be
> combined. But to make things correct, SWUpdate should well integrate
> CASync and uses it as library - this requires some changes in CASync, too. I
> had a draft design about this, but due to the complexity / effort, the project
> asking for delta-update decided in another direction. There is currently no
> further work in SWUpdate in this direction.

Thanks for the update!
Was transforming CASync into a library the complex part that you mention?

Best regards,
Daniel

> 
> Best regards,
> Stefano
> 
> --
> ================================================================
> =====
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
> ================================================================
> =====

[cip-dev] Was: Software updates comparison

[Stefano Babic]

Hi Daniel,

On 15/04/19 11:51, daniel.sangorrin at toshiba.co.jp wrote:
> Hi Stefano,
> 
> Thanks a lot for the clarifications. 
> # Christian (Siemens) had already informed us about part of the progress.
> 

ok

>> From: Stefano Babic <sbabic@denx.de>
> [...]
>> - depends on libubootenv which needs to be rebuilt for each target.
>>
>> This was a well known issue and source of several conflicts in the past.
>> Thanks to a customer of mines, I have implemented a new libubootenv
>> library that is hardware independent and fixes this issue. Not only, this could
>> allow in future to extend it and introduce security features, like signed
>> environment:
>>
>> 	https://github.com/sbabic/libubootenv
>>
>> The library must be explicitely activated in SWUpdate's configuration, it will
>> become the default in future.
> 
> Sounds great.
> I think that SZ Lin (Moxa) was already preparing a Debian package.

I am in touch with him and I have already merged some changes he asked
me to allow an eaier integration of the package in Debian.

> If the new library is mature enough then we should enable it by default.

Most projects of mine are still using the old approach, a couple of
newer have switched to libubootenv. For the future, I will set to
libubootenv as the old approach is often tricky and depends on U-Boot's
changes.

>  
>> - hard to manage updates from v1 to v5 directly
>>
>> This is also a topic I had on my desk - as it is possible to read in your
>> comparison / research, this can be solved if SWUpdate and CASync can be
>> combined. But to make things correct, SWUpdate should well integrate
>> CASync and uses it as library - this requires some changes in CASync, too. I
>> had a draft design about this, but due to the complexity / effort, the project
>> asking for delta-update decided in another direction. There is currently no
>> further work in SWUpdate in this direction.
> 
> Thanks for the update!
> Was transforming CASync into a library the complex part that you mention?

No, it is a part. It must be well integrated in SWUpdate and should not
break the current security concept. SWUpdate implements privilege
separation and processes that communicate with network run with
different permission as the installer, that is generally root. CASync
processes shoult be split and some of them replaced with something
inside SWUpdate.

Best regards,
Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

[cip-dev] Was: Software updates comparison

[Christian Storm]

Hi Scott,

> > > I have added a Software updates comparison report to our wiki:
> > > https://wiki.linuxfoundation.org/civilinfrastructureplatform/cip_comparison_report
> 
> 
> I actually find this comparison surprisingly lacking from a
> security and methodology stand point given that its quite
> limited, and leaves out other well know and not so well known. 
>
> I am sure we dont need to mention the likes of Balena and Mender.....

Well, just for the record....

Balena{,OS} revolves around Docker, e.g., to fetch the firmware
(=container) images prior to extracting them to the spare partition in
A/B deployments. Granted, one could also imagine to use OSTree for this...
Bootloader support is currently grub-efi and u-boot.
As a sidenote: Having reliable firmware update realized with grub is
quite involved, that's -- among other reasons -- why Siemens came up
with EFI Boot Guard [1] for x86/UEFI systems.
So, Balena is quite tied to Docker with all its benefits and drawbacks.

Mender.io can be seen as a one-stop alternative to HawkBit in the
backend plus some agent running on the device as they offer both:
a backend and an according on-device agent.
The on-device agent is written in Golang and tied to the Mender backend.
In terms of features and configurability it's not as advanced as others.
That said, one can implement support for Mender's backend into, e.g.,
SWUpdate quite easily. I already talked to the Mender guys about this...


> I was quite surprised to see RAUC, as it is not so well known
> however...

Well, as an on-device agent not tied to a particular backend, RAUC can
be seen as a competitor to SWUpdate, and hence is usually evaluated as
well for the same use cases.

Both are building blocks for a firmware update solution focusing on the
device-side of things. They are not a one-stop all-in-one solution but
building blocks that are intended to be integrated into a solution.


> your missing ostree, [...]

That depends on what use case you're after. OSTree is a tool for
managing filesystem trees. It is not (primarily) a tool to manage full
disk images. It's somewhere in between with a blend of both approaches'
pros and cons.

That said, there are definitely use cases for OSTree and there speaks
nothing against integrating it into the on-device agents. However, IMO,
doing full disk image firmware updates lends itself to other solutions.
Speaking of OSTree, there's also casync [2] having similar properties,
however, supporting full disk images as well. Once this has become
a proper library, I'm sure it will find its way into SWUpdate.

The question is whether to identify and settle to a particular software/
solution or whether the on-device agent should be flexible enough to
employ different methods serving the many particular -- and naturally
different -- use cases.


> [...] tuf and uptane .. 
> and honestly from a security standpoint this combination far surpasses
> any of the previously mentioned in methodology and implementation.
> Along with OTA Community Edition, it is by far the best solution, far
> more so then hawkbit, swupdate and TUF
> 
> https://uptane.github.io/
> https://github.com/advancedtelematic/...
> https://github.com/advancedtelematic/...

TUF, uptane, aktualizr, and alikes certainly do have their merits, fully
agree. The question here again is what use cases you're after and
whether you want to shop a one-stop all-in-one solution or build/
integrate it using building blocks for the different components.
Granted, in terms of full vertical integration (i.e., backend and
on-device agent), there's surely still work to be done to make a proper
integration of the building blocks, in particular regarding
documentation w.r.t. best (security) practices.
However, I do not see an inherent or general superiority of using TUF,
uptane, aktualizr, or alikes compared to integrating building blocks,
particularly in hindsight to integration flexibility.


Kind regards,
   Christian

[1] https://github.com/siemens/efibootguard
[2] https://github.com/systemd/casync

-- 
Dr. Christian Storm
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Otto-Hahn-Ring 6, 81739 M?nchen, Germany

[cip-dev] Was: Software updates comparison

[daniel.sangorrin at toshiba.co.jp]

> -----Original Message-----
> From: Stefano Babic <sbabic@denx.de>
> Sent: Monday, April 15, 2019 7:03 PM
> To: sangorrin daniel(????? ???? ????????)
> <daniel.sangorrin@toshiba.co.jp>
> Cc: cip-dev at lists.cip-project.org
> Subject: Re: Was: Software updates comparison
> 
> Hi Daniel,
> 
> On 15/04/19 11:51, daniel.sangorrin at toshiba.co.jp wrote:
> > Hi Stefano,
> >
> > Thanks a lot for the clarifications.
> > # Christian (Siemens) had already informed us about part of the progress.
> >
> 
> ok
> 
> >> From: Stefano Babic <sbabic@denx.de>
> > [...]
> >> - depends on libubootenv which needs to be rebuilt for each target.
> >>
> >> This was a well known issue and source of several conflicts in the past.
> >> Thanks to a customer of mines, I have implemented a new libubootenv
> >> library that is hardware independent and fixes this issue. Not only,
> >> this could allow in future to extend it and introduce security
> >> features, like signed
> >> environment:
> >>
> >> 	https://github.com/sbabic/libubootenv
> >>
> >> The library must be explicitely activated in SWUpdate's
> >> configuration, it will become the default in future.
> >
> > Sounds great.
> > I think that SZ Lin (Moxa) was already preparing a Debian package.
> 
> I am in touch with him and I have already merged some changes he asked
> me to allow an eaier integration of the package in Debian.
> 
> > If the new library is mature enough then we should enable it by default.
> 
> Most projects of mine are still using the old approach, a couple of newer
> have switched to libubootenv. For the future, I will set to libubootenv as the
> old approach is often tricky and depends on U-Boot's changes.
> 
> >
> >> - hard to manage updates from v1 to v5 directly
> >>
> >> This is also a topic I had on my desk - as it is possible to read in
> >> your comparison / research, this can be solved if SWUpdate and CASync
> >> can be combined. But to make things correct, SWUpdate should well
> >> integrate CASync and uses it as library - this requires some changes
> >> in CASync, too. I had a draft design about this, but due to the
> >> complexity / effort, the project asking for delta-update decided in
> >> another direction. There is currently no further work in SWUpdate in this
> direction.
> >
> > Thanks for the update!
> > Was transforming CASync into a library the complex part that you mention?
> 
> No, it is a part. It must be well integrated in SWUpdate and should not break
> the current security concept. SWUpdate implements privilege separation and
> processes that communicate with network run with different permission as
> the installer, that is generally root. CASync processes shoult be split and
> some of them replaced with something inside SWUpdate.

I see, that's a valid point.

Thanks,
Daniel

> 
> Best regards,
> Stefano
> 
> --
> ================================================================
> =====
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
> ================================================================
> =====

[cip-dev] Was: Software updates comparison

[daniel.sangorrin at toshiba.co.jp]

Hi Scott!

Thank god that Christian answered, for some reason your e-mail was in my junk folder.

> From: Scott V. Kamp <scottk@optimcloud.com>
> > > I have added a Software updates comparison report to our wiki:
> > > https://wiki.linuxfoundation.org/civilinfrastructureplatform/cip_com
> > > parison_report
> 
> 
> I actually find this comparison surprisingly lacking from a security and
> methodology stand point given that its quite limited, and leaves out other
> well know and not so well known. 

Actually, this is not a "pure" comparison between tools. What we actually did was to read existing comparison reports (see Comparison references at [1]), mix the experience of our members and "compare" which tools aligned best with the requirements of our initial architecture [2].

> I am sure we dont need to mention the
> likes of Balena and Mender..... 

These tools are great but it was obvious to me that they did not satisfy the requirements of our initial architecture [2] so I skipped them right away. 
# this requirements come from a survey between CIP members.
- Balena sounds great if your OS is based on docker containers. I prefer to start with a generic solution that can be used on any OS image.
- Mender server is in the comparison actually and we would like to try it at some point (for the first prototype we use Hawkbit though). The client does not support enough features in the open source version (e.g. delta updates are a strict requirement).

Having said that, I am open to contributions (e.g.: prototypes that show how to update CIP kernel/core with OSS update tools and a text file explaining how it works).  The goal of this workgroup is to show how to use existing OSS update tools with the CIP kernel (LTS kernel + alpha) and CIP Core (Debian-based OS images built from source or binaries). We want to provide them as examples on our reference boards (e.g. BeagleBone Black) so that anyone can start from something that works. In the future I want to add an implementation that uses CASync. If you want to have a try with a different update tool, I will be glad to accept your work for the users of CIP to have more choices.

> I was quite surprised to see RAUC, as it is not
> so well known however... 

Actually I know RAUC because I met his developer on a conference. But the reason that RAUC is there is mostly because it supports CASync (well, not a perfect integration because it is not a library yet). I really like the CASync approach because of its simplicity.

> your missing ostree, tuf and uptane .. and honestly
> from a security standpoint this combination far surpasses any of the
> previously mentioned in methodology and implementation. Along with OTA
> Community Edition, it is by far the best solution, far more so then hawkbit,
> swupdate and TUF
> 
> https://uptane.github.io/
> https://github.com/advancedtelematic/...
> https://github.com/advancedtelematic/...

Actually advancedtelematic/OStree work IS included in the the comparison [1] and is in fact one of the 3 best candidates.
1. SWUpdate+librsync
2. CASync (I added RAUC mostly because it supports CASync)
3. meta-updater (based on OSTree and originally designed by advanced telematic

Here I need your help. I found TUF and Uptane, but I wasn't sure about the difference with meta-updater.
I know meta-updater because it was proposed to be used in AGL by advancedtelematic. Their approach wasn't using A/B updates, which is a requirement for the initial architecture. But we did consider it for devices with small storage, it's just that we left that approach for later.
Do you know the relation and differences between meta-updater/TUF/Uptane. If possible could

Thanks,
Daniel

[1] https://wiki.linuxfoundation.org/civilinfrastructureplatform/cip_comparison_report
[2] https://wiki.linuxfoundation.org/civilinfrastructureplatform/cip_software_updates_architecture

> > >
> > > This comparison is mostly based on other comparisons reports,
> experience from CIP members and from reading the documentation.
> > >
> > > For this initial iteration we decided to prepare a prototype using
> SWUpdate+librsync (for the binary deltas) and ISAR. Having said that, the CIP
> Software updates workgroup is open to other methods and contributions
> (specially in the form of patches). Our aim is to provide guidance and
> reference code/metadata for CIP users to update their devices using existing
> OSS update tools.
> > >
> > > If you think that information in the comparison is not accurate or you
> want to complement it please let me know.
> >
> > Thanks for the document - I am mainly interested on the good and bad
> > points about SWpdate and I can put a couple of details:
> >
> > Bad points
> >
> > - depends on libubootenv which needs to be rebuilt for each target.
> >
> > This was a well known issue and source of several conflicts in the
> > past. Thanks to a customer of mines, I have implemented a new
> > libubootenv library that is hardware independent and fixes this issue.
> > Not only, this could allow in future to extend it and introduce
> > security features, like signed environment:
> >
> > 	https://github.com/sbabic/libubootenv
> >
> > The library must be explicitely activated in SWUpdate's configuration,
> > it will become the default in future.
> >
> > - hard to manage updates from v1 to v5 directly
> >
> > This is also a topic I had on my desk - as it is possible to read in
> > your comparison / research, this can be solved if SWUpdate and CASync
> > can be combined. But to make things correct, SWUpdate should well
> > integrate CASync and uses it as library - this requires some changes
> > in CASync, too. I had a draft design about this, but due to the
> > complexity / effort, the project asking for delta-update decided in
> > another direction. There is currently no further work in SWUpdate in
> > this direction.
> >
> > Best regards,
> > Stefano
> >
> 
> - --
> Sent using Mailpile, Free Software from www.mailpile.is
> 
> -----BEGIN PGP SIGNATURE-----
> 
> iQGzBAEBCgAdFiEED83jmcaGxJZGGerGKdK9XRgP+iUFAlyz3o0ACgkQKdK9XRgP
> +iVBZAv/a9kHLyHdZUbZA1EiJE0WaLwmmD+lp07A9s2cPfNTf5px/8DtbYPrLhm
> 9
> s+atSMbrWUl1R7v1hmZ6tPmZpXAOz+EJgknoRr40+FlBIgF/MZvnq29Zg91igKcG
> ZEHJq1AJl68dzm5O70DGoMIrxZ/k2WAeElZ+JPR7aN7RiYCNm4qTwvt/QLpNw
> muT
> Hr+sDZvWbomGd/VwuXuttW6o/Lpq1al9GljmedBsycBcPCWkc6G7eupyoNSTN
> mli
> jKvwlxx/5loapVDMuI+l2cQX6MVVTSrhqGxhB1w2SFmZBsWDgFV/snds9rK4Q6
> KE
> SS4sLsM2PxrFK/fRFHHUzUPc4thmnRHOp0XOR3+qRen2MyVeQxJjlouTBn9nCS
> Oy
> wy5zh10QAMboC0H5HARnS4fWOrwpwEfFPX16s+uSMbF36JJMyqokk23Z5asx
> QTV8
> +YBV9tJch1U311BUG4zS8yTKm1kRSDbGQs21V5xxPirKhsFTepwgLfwbTSK+cxjk
> MyCZR5wM
> =7PB7
> -----END PGP SIGNATURE-----

[cip-dev] Was: Software updates comparison

[daniel.sangorrin at toshiba.co.jp]

Oops, I sent it too quickly.

> I know meta-updater because it was proposed to be used in AGL by
> advancedtelematic. Their approach wasn't using A/B updates, which is a
> requirement for the initial architecture. But we did consider it for devices
> with small storage, it's just that we left that approach for later.
> Do you know the relation and differences between meta-
> updater/TUF/Uptane. If possible could

If possible could you tell us whether they align to the requirements of the initial architecture?
- A/B updates (the bootloader controls a hardware watchdog)
- Delta support (low bandwidth)
- Generic (can support any OS image builder such as meta-debian or ISAR)
- Low dependencies (no python or similar dependencies)
- Support for custom scripts

Thanks,
Daniel

> 
> Thanks,
> Daniel
> 
> [1]
> https://wiki.linuxfoundation.org/civilinfrastructureplatform/cip_comparison
> _report
> [2]
> https://wiki.linuxfoundation.org/civilinfrastructureplatform/cip_software_u
> pdates_architecture
> 
> > > >
> > > > This comparison is mostly based on other comparisons reports,
> > experience from CIP members and from reading the documentation.
> > > >
> > > > For this initial iteration we decided to prepare a prototype using
> > SWUpdate+librsync (for the binary deltas) and ISAR. Having said that,
> > SWUpdate+the CIP
> > Software updates workgroup is open to other methods and contributions
> > (specially in the form of patches). Our aim is to provide guidance and
> > reference code/metadata for CIP users to update their devices using
> > existing OSS update tools.
> > > >
> > > > If you think that information in the comparison is not accurate or
> > > > you
> > want to complement it please let me know.
> > >
> > > Thanks for the document - I am mainly interested on the good and bad
> > > points about SWpdate and I can put a couple of details:
> > >
> > > Bad points
> > >
> > > - depends on libubootenv which needs to be rebuilt for each target.
> > >
> > > This was a well known issue and source of several conflicts in the
> > > past. Thanks to a customer of mines, I have implemented a new
> > > libubootenv library that is hardware independent and fixes this issue.
> > > Not only, this could allow in future to extend it and introduce
> > > security features, like signed environment:
> > >
> > > 	https://github.com/sbabic/libubootenv
> > >
> > > The library must be explicitely activated in SWUpdate's
> > > configuration, it will become the default in future.
> > >
> > > - hard to manage updates from v1 to v5 directly
> > >
> > > This is also a topic I had on my desk - as it is possible to read in
> > > your comparison / research, this can be solved if SWUpdate and
> > > CASync can be combined. But to make things correct, SWUpdate should
> > > well integrate CASync and uses it as library - this requires some
> > > changes in CASync, too. I had a draft design about this, but due to
> > > the complexity / effort, the project asking for delta-update decided
> > > in another direction. There is currently no further work in SWUpdate
> > > in this direction.
> > >
> > > Best regards,
> > > Stefano
> > >
> >
> > - --
> > Sent using Mailpile, Free Software from www.mailpile.is
> >
> > -----BEGIN PGP SIGNATURE-----
> >
> >
> iQGzBAEBCgAdFiEED83jmcaGxJZGGerGKdK9XRgP+iUFAlyz3o0ACgkQKdK9XRgP
> >
> +iVBZAv/a9kHLyHdZUbZA1EiJE0WaLwmmD+lp07A9s2cPfNTf5px/8DtbYPrLhm
> > 9
> >
> s+atSMbrWUl1R7v1hmZ6tPmZpXAOz+EJgknoRr40+FlBIgF/MZvnq29Zg91igKcG
> >
> ZEHJq1AJl68dzm5O70DGoMIrxZ/k2WAeElZ+JPR7aN7RiYCNm4qTwvt/QLpNw
> > muT
> >
> Hr+sDZvWbomGd/VwuXuttW6o/Lpq1al9GljmedBsycBcPCWkc6G7eupyoNSTN
> > mli
> >
> jKvwlxx/5loapVDMuI+l2cQX6MVVTSrhqGxhB1w2SFmZBsWDgFV/snds9rK4Q6
> > KE
> >
> SS4sLsM2PxrFK/fRFHHUzUPc4thmnRHOp0XOR3+qRen2MyVeQxJjlouTBn9nCS
> > Oy
> >
> wy5zh10QAMboC0H5HARnS4fWOrwpwEfFPX16s+uSMbF36JJMyqokk23Z5asx
> > QTV8
> >
> +YBV9tJch1U311BUG4zS8yTKm1kRSDbGQs21V5xxPirKhsFTepwgLfwbTSK+cxjk
> > MyCZR5wM
> > =7PB7
> > -----END PGP SIGNATURE-----
> _______________________________________________
> cip-dev mailing list
> cip-dev at lists.cip-project.org
> https://lists.cip-project.org/mailman/listinfo/cip-dev

[cip-dev] Was: Software updates comparison

[nobuhiro1.iwamatsu at toshiba.co.jp]

Hi Stefano,

> >> 	https://github.com/sbabic/libubootenv
> >>
> >> The library must be explicitely activated in SWUpdate's
> >> configuration, it will become the default in future.
> >
> > Sounds great.
> > I think that SZ Lin (Moxa) was already preparing a Debian package.
> 
> I am in touch with him and I have already merged some changes he asked
> me to allow an eaier integration of the package in Debian.

Oh, I already packaged this with some patches.
You can see data from salsa.debian.org:
   https://salsa.debian.org/debian/libubootenv

If there is a necessary patch in this, please apply.

Best regards,
  Nobuhiro

> -----Original Message-----
> From: cip-dev-bounces at lists.cip-project.org
> [mailto:cip-dev-bounces at lists.cip-project.org] On Behalf Of Stefano
> Babic
> Sent: Monday, April 15, 2019 7:03 PM
> To: sangorrin daniel(????? ???? ????????)
> <daniel.sangorrin@toshiba.co.jp>
> Cc: cip-dev at lists.cip-project.org
> Subject: Re: [cip-dev] Was: Software updates comparison
> 
> Hi Daniel,
> 
> On 15/04/19 11:51, daniel.sangorrin at toshiba.co.jp wrote:
> > Hi Stefano,
> >
> > Thanks a lot for the clarifications.
> > # Christian (Siemens) had already informed us about part of the progress.
> >
> 
> ok
> 
> >> From: Stefano Babic <sbabic@denx.de>
> > [...]
> >> - depends on libubootenv which needs to be rebuilt for each target.
> >>
> >> This was a well known issue and source of several conflicts in the
> past.
> >> Thanks to a customer of mines, I have implemented a new libubootenv
> >> library that is hardware independent and fixes this issue. Not only,
> >> this could allow in future to extend it and introduce security
> >> features, like signed
> >> environment:
> >>
> >> 	https://github.com/sbabic/libubootenv
> >>
> >> The library must be explicitely activated in SWUpdate's
> >> configuration, it will become the default in future.
> >
> > Sounds great.
> > I think that SZ Lin (Moxa) was already preparing a Debian package.
> 
> I am in touch with him and I have already merged some changes he asked
> me to allow an eaier integration of the package in Debian.
> 
> > If the new library is mature enough then we should enable it by default.
> 
> Most projects of mine are still using the old approach, a couple of newer
> have switched to libubootenv. For the future, I will set to libubootenv
> as the old approach is often tricky and depends on U-Boot's changes.
> 
> >
> >> - hard to manage updates from v1 to v5 directly
> >>
> >> This is also a topic I had on my desk - as it is possible to read in
> >> your comparison / research, this can be solved if SWUpdate and CASync
> >> can be combined. But to make things correct, SWUpdate should well
> >> integrate CASync and uses it as library - this requires some changes
> >> in CASync, too. I had a draft design about this, but due to the
> >> complexity / effort, the project asking for delta-update decided in
> >> another direction. There is currently no further work in SWUpdate in
> this direction.
> >
> > Thanks for the update!
> > Was transforming CASync into a library the complex part that you mention?
> 
> No, it is a part. It must be well integrated in SWUpdate and should not
> break the current security concept. SWUpdate implements privilege
> separation and processes that communicate with network run with different
> permission as the installer, that is generally root. CASync processes
> shoult be split and some of them replaced with something inside SWUpdate.
> 
> Best regards,
> Stefano
> 
> --
> ====================================================================
> =
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
> ====================================================================
> =
> _______________________________________________
> cip-dev mailing list
> cip-dev at lists.cip-project.org
> https://lists.cip-project.org/mailman/listinfo/cip-dev

[cip-dev] Was: Software updates comparison

[SZ Lin (林上智)]

Hi,
Stefano Babic <sbabic@denx.de> ? 2019?4?15? ?? ??6:03???

<snip>

> > Sounds great.
> > I think that SZ Lin (Moxa) was already preparing a Debian package.
>
> I am in touch with him and I have already merged some changes he asked
> me to allow an eaier integration of the package in Debian.

As we discussed, please reconfirm the license changes below

1. GPL-2+ with OpenSSL exception [1]

I've marked below files with "GPL-2+ with OpenSSL exception" since
these are OpenSSL-dependent

- corelib/channel_curl.c
- corelib/verify_signature.c
- corelib/swupdate_rsa_verify.c
- corelib/swupdate_decrypt.c
- corelib/test/test_crypt.c
- corelib/swupdate_cms_verify.c
- core/cpio_utils.c
- core/swupdate.c
- core/parser.c
- corelib/swupdate_verify_private.h

[1] https://salsa.debian.org/szlin/swupdate/blob/debian/master/debian/copyright#L27

2. {Expat and} GPL-2 with OpenSSL exception

I've marked below file with "Expat and GPL-2 with OpenSSL exception."
since this file includes "mongoose.h" which is GPL-2 only.
Besides, I'll suggest removing Expat since it will turn to GPL-2 after all.

- mongoose_interface.c

[2] https://salsa.debian.org/szlin/swupdate/blob/debian/master/debian/copyright#L39

SZ

>
> > If the new library is mature enough then we should enable it by default.
>
> Most projects of mine are still using the old approach, a couple of
> newer have switched to libubootenv. For the future, I will set to
> libubootenv as the old approach is often tricky and depends on U-Boot's
> changes.
>
> >
> >> - hard to manage updates from v1 to v5 directly
> >>
> >> This is also a topic I had on my desk - as it is possible to read in your
> >> comparison / research, this can be solved if SWUpdate and CASync can be
> >> combined. But to make things correct, SWUpdate should well integrate
> >> CASync and uses it as library - this requires some changes in CASync, too. I
> >> had a draft design about this, but due to the complexity / effort, the project
> >> asking for delta-update decided in another direction. There is currently no
> >> further work in SWUpdate in this direction.
> >
> > Thanks for the update!
> > Was transforming CASync into a library the complex part that you mention?
>
> No, it is a part. It must be well integrated in SWUpdate and should not
> break the current security concept. SWUpdate implements privilege
> separation and processes that communicate with network run with
> different permission as the installer, that is generally root. CASync
> processes shoult be split and some of them replaced with something
> inside SWUpdate.
>
> Best regards,
> Stefano
>
> --
> =====================================================================
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
> =====================================================================
> _______________________________________________
> cip-dev mailing list
> cip-dev at lists.cip-project.org
> https://lists.cip-project.org/mailman/listinfo/cip-dev

[cip-dev] Was: Software updates comparison

[Stefano Babic]

Hi,

On 16/04/19 17:07, SZ Lin (???) wrote:
> Hi,
> Stefano Babic <sbabic@denx.de> ? 2019?4?15? ?? ??6:03???
> 
> <snip>
> 
>>> Sounds great.
>>> I think that SZ Lin (Moxa) was already preparing a Debian package.
>>
>> I am in touch with him and I have already merged some changes he asked
>> me to allow an eaier integration of the package in Debian.
> 
> As we discussed, please reconfirm the license changes below
> 

Ok

> 1. GPL-2+ with OpenSSL exception [1]
> 
> I've marked below files with "GPL-2+ with OpenSSL exception" since
> these are OpenSSL-dependent
> 
> - corelib/channel_curl.c
> - corelib/verify_signature.c
> - corelib/swupdate_rsa_verify.c
> - corelib/swupdate_decrypt.c
> - corelib/test/test_crypt.c
> - corelib/swupdate_cms_verify.c
> - core/cpio_utils.c
> - core/swupdate.c
> - core/parser.c
> - corelib/swupdate_verify_private.h
> 

Yes - these files include openssl.h, and for them the OpenSSL exception
is required. As you told me that SPDX has finally released an identifier
for it, I could also change the ID for that files for next version of
SWUpdate, (a 2019.04 release will be pushed on next days).

> [1] https://salsa.debian.org/szlin/swupdate/blob/debian/master/debian/copyright#L27
> 
> 2. {Expat and} GPL-2 with OpenSSL exception
> 
> I've marked below file with "Expat and GPL-2 with OpenSSL exception."
> since this file includes "mongoose.h" which is GPL-2 only.
> Besides, I'll suggest removing Expat since it will turn to GPL-2 after all.
> 

Yes, agree.

> - mongoose_interface.c
> 
> [2] https://salsa.debian.org/szlin/swupdate/blob/debian/master/debian/copyright#L39
> 

Best regards,
Stefano Babic


-- 
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================