[PATCH 00/10] Add build and target hash for test results

[Gedare Bloom]

On Wed, Feb 24, 2021 at 11:55 AM Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
>
> On 24/02/2021 19:49, Gedare Bloom wrote:
>
> > On Wed, Feb 24, 2021 at 11:36 AM Sebastian Huber
> > <sebastian.huber at embedded-brains.de>  wrote:
> >> On 24/02/2021 19:22, Gedare Bloom wrote:
> >>
> >>> On Wed, Feb 24, 2021 at 6:57 AM Sebastian Huber
> >>> <sebastian.huber at embedded-brains.de>   wrote:
> >>>> This patch set adds the new directives rtems_get_build_hash() and
> >>>> rtems_get_target_hash() which can be used to differentiate test suite
> >>>> results.  See also the following discussion:
> >>>>
> >>>> https://lists.rtems.org/pipermail/devel/2020-November/063226.html
> >>>>
> >>>> Sebastian Huber (10):
> >>>>     build: Generate build hash
> >>>>     rtems: Add rtems_get_build_hash()
> >>>>     libtest: Report build hash
> >>>>     score: Add _IO_Base64url()
> >>>>     score: Add Hash Handler
> >>>>     rtems: Add rtems_get_target_hash()
> >>>>     Add system initialization step for target hash
> >>>>     bsps: Add default rtems_get_target_hash()
> >>>>     libtest: Report target hash
> >>>>     libtest: Print SHA256 hash in base64url
> >>>>
> >>> Is there a good reason to use SHA256 over a lighter weight algorithm?
> >>> I guess I wonder about the overhead and value of using it.
> >>>
> >>> We don't need cryptographic security here, we just need a reasonably
> >>> non-colliding checksum. The speed of hashing will matter for running
> >>> testsuites.
> >> SHA256 is currently the best algorithm for 32-bit targets we have in the
> >> RTEMS sources. It is also selected for the next Git hash. I don't think
> >> the time to calculate the hash really matters and I want to avoid any
> >> discussions if MD5 is sufficient or not.
> >>
> > OK, from a code existence argument this is fine. I could even see a
> > possibility to fold in the source code hashes in the future to make a
> > "secure" checksum that can be verified at boot-time.
> >
> If the hash algorithm turns out to be an issue, we can change it. From
> an API point of view it doesn't matter. It just has to be a some string.
>
OK I see that, this is fine. Thanks

> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.huber at embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>