Vulnerability RSS feed reuses same page/URL/guid so RSS watchers aren't notified when new security releases are available

[pdehaan]

Enter your suggestions in details:

Sorry, possibly a bit of an edge case here... I just added https://nodejs.org/en/feed/vulnerability.xml to one of our company's Slack channels so we get pinged in-channel about new security updates. So far so good. But apparently 30 minutes ago the new Node 18+20 builds were ready but the RSS didn't update to trigger Slack updates.

1. Follow https://nodejs.org/en/feed/vulnerability.xml
2. https://groups.google.com/g/nodejs-sec/c/m_wMICiQrlM says:
   • "The Node.js project will release new versions of all supported release lines on or shortly after Friday October 13 2023. For more information see: https://nodejs.org/en/blog/vulnerability/october-2023-security-releases"
   • "The planned security releases are now available. You can read more about the details in https://nodejs.org/en/blog/vulnerability/october-2023-security-releases."
3. Note that both URLs in the nodejs-sec Google Group point to the same page/post.
4. Not sure if RSS/Slack/Feedly is determining new content by a change to a guid or new link tag, but looks like neither changed when the new releases were available since the page was updated, not a new page.

   <link>https://nodejs.org/en/blog/vulnerability/october-2023-security-releases</link>
   <guid>/blog/vulnerability/october-2023-security-releases</guid>

I could instead follow https://nodejs.org/en/feed/releases.xml for new Node releases in our Slack RSS integration, but then that'd notify us on EVERY new release, not just sec-releases. Not sure if it's possible to modify the guid/link with some hash or timestamp to cause it to invalidate when the page is updated. 🙏

[bmuenzenmeyer]

thanks for the report - i can seee how the current process of reuse leads to this. I and others need to research what you describe as a way to cache bust this

[pdehaan]

Not sure if it'd work, but my first theory was possibly converting the pubDate to an time integer and seeing if I could add that to a cache busting hash (or query param) after the link and guid. Although that assumes that the pubDate updates whenever you update the page contents.

Date.parse("Fri, 13 Oct 2023 13:30:00 GMT").getTime()
// 1697203800000

<item>
  <title>
    <![CDATA[ Friday October 13 2023 Security Releases ]]>
  </title>
  <link>https://nodejs.org/en/blog/vulnerability/october-2023-security-releases#1697203800000</link>
  <guid isPermaLink="false">/blog/vulnerability/october-2023-security-releases#1697203800000</guid>
  <pubDate>Fri, 13 Oct 2023 13:30:00 GMT</pubDate>
</item>

[ovflowd]

Not sure if it'd work, but my first theory was possibly converting the pubDate to an time integer and seeing if I could add that to a cache busting hash (or query param) after the link and guid. Although that assumes that the pubDate updates whenever you update the page contents.

Date.parse("Fri, 13 Oct 2023 13:30:00 GMT").getTime()
// 1697203800000

<item>
  <title>
    <![CDATA[ Friday October 13 2023 Security Releases ]]>
  </title>
  <link>https://nodejs.org/en/blog/vulnerability/october-2023-security-releases#1697203800000</link>
  <guid isPermaLink="false">/blog/vulnerability/october-2023-security-releases#1697203800000</guid>
  <pubDate>Fri, 13 Oct 2023 13:30:00 GMT</pubDate>
</item>

That sounds like a doable fix. Pretty much appending an unix timestamp to the URL? I believe that can easily be done. Would you be inclined by opening a PR?