镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

Include link to blog post in security-release email #38143

Description

@WaleedAshraf

The recent security release email for 6-Apr-2021 had two broken links for the versions.

Broken:

Correct:

Link for v15.14.0 was fixed by @Trott later here: nodejs/nodejs.org#3794
For v12.22.1, seems it was a typo in the email. The blog post had the correct link.

Suggestion:

There was no link to the actual blog post (https://nodejs.org/en/blog/vulnerability/april-2021-security-releases/) in the email. So, there was no way to navigate to the updated version from the email.

Would it be better if we don't include links to the individual versions in the email, rather include link to the blog post. In that case, the blog post can be fixed and stays up to date.

cc @nodejs/security-release

Activity

  1. nschonni commented on Apr 7, 2021

    @nschonni
    Member

    Don't think this is the right repo. There is nothing here that sends out any emails. If you're talking about general GitHub notifications, that's not something we have control over

  2. richardlau commented on Apr 8, 2021

    @richardlau
    Member

    This is referring to the emails sent to the mailing list (https://groups.google.com/group/nodejs-sec) as per the security release process. I'll move this over to core because that's where the process doc lives.

  3. added
    metaIssues and PRs related to the general management of the project.
    on Apr 8, 2021
  4. richardlau commented on Apr 8, 2021

    @richardlau
    Member

    cc @danbev @mhdawson as the most recent people to have run through this process for their thoughts on the suggestion.

  5. danbev commented on Apr 8, 2021

    @danbev
    Contributor

    I've replied with a message to the group: https://groups.google.com/u/1/g/nodejs-sec/c/TXKhlMr55UA, and provided a like to the blog post as well.

    Would it be better if we don't include links to the individual versions in the email, rather include link to the blog post

    I think we could do that or we could include a link to the blog post in addition to the copied information.

  6. WaleedAshraf commented on Apr 8, 2021

    @WaleedAshraf
    ContributorAuthor

    @danbev Thanks for the correction email. Would have been better if you also included the correct link for v12. But it's fine, as the link to the blog is also included.

    I'm not sure if there's a template for these emails which we can update to always include a link to the blog. If the release/security team thinks it'd be good to include.

  7. mhdawson commented on Apr 8, 2021

    @mhdawson
    Member

    I think reducing to a single source of truth makes sense to me. The messages to the nodejs-sec mailing list could then just include the link to the blog post, and possibly the "Contact and future updates" section.

    One thing I failed to notice earlier (my bad for not catching in review is that the lastest updates to the blog post did not keep the initial announce at the bottom. An example were we did that is: https://nodejs.org/en/blog/vulnerability/november-2020-security-releases/. I think if we do that for future ones, then having a reference in the email versus duplicated content will provide the same info, as well as making it easier for the security release steward.

    @danbev does that make sense to you?

  8. danbev commented on Apr 9, 2021

    @danbev
    Contributor

    Yeah, that makes sense to just have a link to the blog post and also save the pre-announcement in the real announcement 👍
    I'll update the security release process doc with this.

  9. added a commit that references this issue on Apr 29, 2021
  10. richardlau commented on Feb 17, 2022

    @richardlau
    Member

    The email template in the security release process guide was updated in #38290 and recent emails, e.g. https://groups.google.com/g/nodejs-sec/c/xIj1bpCtY3I, contain links to the relevant blog post.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    metaIssues and PRs related to the general management of the project.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions