nettle-bugs September 2016

nettle-bugs@lists.lysator.liu.se

3 participants
5 discussions

use gitlab's shared runners
by Nikos Mavrogiannopoulos 14 Sep '16

14 Sep '16

Hi, This patch converts nettle's CI to use gitlab's infrastructure. Red Hat's specific runners currently used for CI will be phased out, so it makes sense to switch to gitlab.com shared infrastructure. An other advantage is that more (Linux) systems can be checked due to the fact that this CI is based on docker. An example run can be seen at: https://gitlab.com/gnutls/nettle/pipelines/4146073 regards, Nikos

3 4

plan for 3.3
by Nikos Mavrogiannopoulos 06 Sep '16

06 Sep '16

Hi, Some comments on the 3.3, plan: > + Add larger "safe" curves, e.g., M-383, curve41417, curve448 and > + E-521. I think curve448 should be prioritized over anything else since it seems to be the only thing being standardized at the moment by CFRG: https://tools.ietf.org/html/rfc7748 For password hashing (pbkdf2), it may also worth considering to add support for argon2,which seems to be the only password hashing algorithm coming out of a competition: https://password-hashing.net/ > Side-channel silent mem_equalp. Do you mean a function with run time independent of its input values? I have such a function at gnutls: https://gitlab.com/gnutls/gnutls/blob/master/lib/safe-memfuncs.c#L70 regards, Nikos

2 3

TLS 1.3 in gnutls
by Nikos Mavrogiannopoulos 05 Sep '16

05 Sep '16

Hi, I've tried to make a rough sketch of the requirements needed to support TLS 1.3 in gnutls. I've split the task in sub-tasks on [0]. Some need to be handled in gnutls and some need to be handled in nettle. Do you think I've missed something, or there are tasks that can be further split? About the nettle additions, is there anyone already working or willing to work on these? On the gnutls part is there anyone already working or willing to work on the missing parts? regards, Nikos [0]. https://gitlab.com/gnutls/gnutls/milestones/8

2 2

display code coverage
by Nikos Mavrogiannopoulos 05 Sep '16

05 Sep '16

Hi, The attached patch uses lcov to display the code coverage of the test suite. It uses ax_code_coverage.m4 which assumes automake, so this patch modifies it to be able to work. This is a preliminary patch to demo the functionality, as I haven't gone through all the automake- related variables. regards, Nikos

2 1

char vs uint8_t
by nisse＠lysator.liu.se 03 Sep '16

03 Sep '16

I'd like to eliminate pointer-signedness warnings. I'm afraid some ugly casts will have to be involved, since most functions work with uint8_t, and at least test code needs to pass literal strings, of type char *. I have one question, on the ascii-armor funtions: Would ie make sense to change the type of ascii inputs and outputs to char? I.e., size_t base64_encode_update(struct base64_encode_ctx *ctx, - uint8_t *dst, + char *dst, size_t length, const uint8_t *src); and similarly for all related functions. It would be an API change but not an ABI change for any ABI spec I'm aware of. What do you think? So the input to encoding is an octet string (uint8_t), and the output is a string of plain char. And vice versa for decoding functions. Also applies to the type arguments for sexp_iterator_check_type, sexp_iterator_check_types and sexp_iterator_assoc, currently using uint8_t. They are usually called with literal ascii strings, so it would make some sense to type as char rather than uint8_t. (I don't think these are used much by any application except lsh and libspki). And no matter how things are typed, I wouldn't expect nettle to work out of the box on platforms where char and uint8_t are of different size, or where string literals use a non-asciii character set. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

nettle-bugs September 2016