Shibboleth Developer's Meeting, 2023-10-20

Call Administrivia

09:00 Central US / 10:00 Eastern US / 15:00 UK / 17:00 FI

Calls are normally the 1st and 3rd Fridays of each month. Next call would be Friday 2023-11-03. Any reason to deviate from this?

60 to 90 minute call window.

Call Details

This week's call will use the Zoom system at GU, see ZoomGU for access info.

AGENDA

1. Propose we release updated 17 parent and re-lock everything to that to stablize javadoc mess

   1. Unless we’ve decided to start leaving everything unlocked and letting dependency updates bleed into all the CI jobs?

   2. If there are additional release profile changes we want to make, might be a good time.

   3. Decision is to leave it all unlocked for now, and we’ll assume a full re-release next time. Patch-compatible dependencies can be updated at this point.

2. Overall backlog of new work / release planning

   1. Confirmed, no outstanding V4 work right now, work on V5 is primarily feature (5.1) stuff so targeting maybe early December for that along with some minor updates to plugins for features there.

3. Board update

Attendees:

Brent

• 

  • tested their changes and our update is ready to go. xmlsec 3.0.3 was released Thurs (yesterday).

  • need to update xmlsec dep to 3.0.3 - wrt to the agenda topic: do in java-parent or override in opensaml-parent, etc?

• 

  • Can default these in TLSSocketFactory impl itself, and can be overridden either at factory-level or per-request if necessary (the latter most likely)

    • Minor risk is if we have any gaps where we don’t have an HttpClientSecurityParameters that can be supplied to override

  • Should extrapolate to cipher suites also? Maybe hardening the protocols would already limit the “bad ones” inherently.

• 

  • I have observations not expressed in the issue yet. No resolution yet. Summary:

    • I think the issue isn’t use of xsi:type per se, it’s any case where you don’t have XMLObject support for an element/type in your runtime environment, and you get an XSAny.

    • If I remember XML Schema esoterica correctly (maybe not), any element’s content model can be subtyped - it’s just not common. I.e. RoleDescriptor isn’t special.

      • <KeyDescriptor xsi:type="brent:MyAwesomeKeyDescriptorType"> - where that type is a subtype of KeyDescriptorType.

      • Is a theoretical concern, maybe we just ignore and focus on the “expected” extension points.

Daniel

• Nothing to report.

Henri

• 

  • Propagation: found a way to control the front-channel propagation result in UI

    • The propagation flow calls the RP’s front-channel logout URI in yet another iframe, but proceeds itself into the similar end-state as back-channel does

  • RP-initiated logout:

    • Mostly done now, also including some initial flow tests (first flow test for me with a flow resuming from a view)

    • Some fine-tuning needed for id_token_hint validation (first case when OP is validating its own signatures)

  • TODO

    • Finish unit / flow tests

    • Tests against the conformance suite

    • Documentation

Ian

John

• 

  • Eventually prevailed. Short version: found no way to do this without a subscription; and, winner of the WTF-of-the-month award, RHEL AMIs ship with a non-obvious, non-default (by Red Hat’s own definition) setting that disables full RPM repos on subscribed machines.

  • I have a patch for the make $COMPONENT regression that affects the curl-openssl component. Working on test builds for that today.

Marvin

Phil

• Not overly productive, but…

• I hacked it, but maybe that can work, tbc.

• Started looking at a webauthn authentication plugin.

  • Basic plugin structure created and committed.

  • Also, some more minor cleanups to the archetype.

Rod

• Wix4 work currently stalled

  • Waiting for the Wix project to show that they care about Supply chain work

  • Unsure about packaging

• EDS - displacing madly.

Scott

• Ongoing work on javadocs

  • Any javadocs used by other projects are deployed now under /api

  • Site jobs for both branches converted to build and deploy the aggregate javadoc jar for snapshots

    • Significant variability encountered using the Maven options box vs. the command line box

    • Unable to find a simple way to get Maven to build and deploy just the javadoc, it wants to build all the code and deploy all the jars it built. This means for now the site jobs will actually deploy another snapshot. It doesn’t build all the individual javadocs like the main build profiles do, so the jobs are still pretty fast.

  • Release profile used by nightlies no longer include any javadoc goals, verified docs not being deployed to Nexus nightly anymore

• 

  • We should have some fairly self-contained ways to generate hashes needed for inline scripts

  • Straddles the bug/enhancement line vis a vis when/how to release changes, OTOH a minor update is “freeing”

• 

• 

  • A regression but does not break (proper) upgrades (i.e., you know it’s going to bite people)

Tom

• 
  Problem being bin/install.sh is not being made executable if the sign-snapshots profile is active
  Cause seems to be that Maven plugins (in this case maven-antrun-plugin) are called once with multiple executions
  So activating the sign-snapshots plugin calls make-files-in-bin-executable after the assembly is built
  Workarounds ? maybe use the assembly plugin to change the filemode
  

Other