sbp commented on issue #1395: URL: https://github.com/apache/tooling-trusted-releases/issues/1395#issuecomment-5050520704
These findings are preliminary. (1) **LDAP** ATR does not read the error messages associated with LDAP failures, so it treats the empty list as an indication that the user has been banned, and revokes access by destroying all existing sessions. This is not as harsh as it sounds, because the only consequence is that users will have to authenticate again once LDAP is back up. But the error messages that we send are inaccurate, so for that alone we should make the small changes necessary for ATR to read the LDAP errors and distinguish between the two failure cases. (2) **SVN dist** When SVN fails, the task to publish the error will fail and write a notification to the user through the site notification mechanism. The error message will be "SVN publish failed; see worker logs for details". Users cannot read worker logs, so we should try to catch as many known possible errors as we can and format better messages. In any case, the consequence for the user is the same: they have to try again later. (3) **downloads.apache.org** The announce POST might stall, so we should tighten the timeout. If the site is down, I decided to make it fail leniently and permit the release, but it would be better to do the opposite and fail strictly, preventing the release until `downloads.apache.org` is back up for us to check. If the site is down, it doesn't make much sense to perform the announcement then anyway. There are some additional external resources that we use: * `lists.apache.org` (vote tabulation, thread fetching) * Our internal mail relay (all outbound email) * The PubSub service (ban propagation, commit cataloguing) * MFA OAuth (consequences of this being down are obvious) * GitHub (Trusted Publishing, source tree comparisons, workflows) * OSV and deps.dev (SBOM checks) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
