Weekly Standup

Hosted by wk on Mar 2 2020, 11:00 AM - 12:00 PM.

Recurring Event

Event Series
This event is an instance of E376: Weekly Standup, and repeats every week.


gniibe is attending this event.Mar 2 2020, 3:25 AM
gniibe added a subscriber: gniibe.Mar 2 2020, 3:46 AM

About security@gnupg.org:

  • In my own opinion, Intel SGX would be "out of scope"
    • but I don't have a concrete idea how we could draw a clear line, or how we could explain our threat model well
  • For me, the reports on the table are: it's not worth asking an assignment of CVE (or two)
  • My action (of plan):
    • Only apply ec_invm change to libgcrypt
      • so that it follows a standard practice of ECC computation recommendation, which can be seen in Ed25519
  • May I ask Werner... to write back to reporters our decision?

Last two weeks:

This week:

  • GnuPG/gpg-card: list of key algorithm for Gnuk
  • libksba and gpgsm: ECC support
  • Poldi, a bit
werner added a subscriber: werner.Mar 2 2020, 8:25 AM

Last week:

  • Global config for GnuPG

This week:

  • Card tests and new features for gpg-card

What to discuss:
How should gpgconf work. Whilst working on adding global config support also to gpgconf I found a couple of problems:

  • It it cumbersome to maintain options which shall be changeable with gpgconf.
  • gpgconf does not use our standard option parser (because it does not know the options)
  • It seems dirmngr options are not translated (due to the use of the old dirmngr domain)
  • The option--gpgconf-list partly takes defaults from options.

I have ideas on how to change this but we need to see what priority we want to give them.

I worked mostly on Packaging, especially our MSI stuff. I'll try to finish that this week.

On the other hand I will try to work more on gpgcard user interface this week. My main goal there is to generate OpenPGP keys from an S/MIME smartcard.

And I also have to tell @dkg that he is not the maintainer of GnuPG. *Sigh*

aheinecke is attending this event.Mar 2 2020, 9:38 AM

I had a quick look at slibtool. The one feature which is missing is parsing a def file so that we will have a weel defined list of exports with their ordinals. Moving this to an explicit invocation of dlltool seens to be needed, I am not sure. That would be a step back.

The code is a bit questionable: I see sprintf (pointer, "%s/foo", some_other_arg) style code where POINTER is provided by the caller and there is no easy way to figure out how long the allocated buffer is. And that POINTER is also move forward within the buffer for another sprintf. Might all be okay, but without an explicit length check for the buffer I would feel uneasy.