Commit suggestions from @duckinator

Co-authored-by: Ellen Marie Dash <the@smallest.dog>

Author: indirect

_posts/2024-03-31-rubygems-and-xz.md

@@ -5,19 +5,19 @@ author: Samuel Giddins
 author_email: segiddins@segiddins.me
 ---
 
-The past few days have seen the security world focused on the revelation of the [xy/liblzma backdoor](https://xeiaso.net/notes/2024/xz-vuln/), which has been assigned [CVE-2024-3094](https://nvd.nist.gov/vuln/detail/CVE-2024-3094).
+The past few days have seen the security world focused on the revelation of the [xz/liblzma backdoor](https://xeiaso.net/notes/2024/xz-vuln/), which has been assigned [CVE-2024-3094](https://nvd.nist.gov/vuln/detail/CVE-2024-3094).
 
 In response to this, I have undertaken an exposure assesment of the vulnerability on RubyGems.org and the broader RubyGems ecosystem.
-I am happy to report that RubyGems.org is not vulnerable to this issue, as we use a `musl` based operating system (Alpine) for our RubyGems.org containers.
+I am happy to report that RubyGems.org is not vulnerable to this issue, as our servers use a `musl` based operating system (Alpine).
 
 Furthermore, I am happy to confirm that there is no evidence that gems in the RubyGems ecosystem have been used as an attack vector for this vulnerability.
 Thanks to the data consolidated in the [rubygems-research](https://github.com/segiddins/rubygems-research) project (available publicly at [research.rubygems.info](https://research.rubygems.info)), we can confirm that no gems contain any references to the vulnerable `liblzma` library.
 
 I would like to thank the rest of the RubyGems.org security team for their support in this investigation, and for their continued dedication to the security of the ecosystem. I would also like to thank AWS for their continued support of RubyGems security, sponsoring myself as [Ruby Central's security engineer in residence](https://rubycentral.org/news/ruby-central-welcomes-new-software-engineer-in-residence-sponsored-by-aws/), and funding the development of the [rubygems-research](https://github.com/segiddins/rubygems-research) project, which proved instrumental in confirming the absence of `liblzma` across all million and a half gem versions hosted on RubyGems.org.
 
-## Nitty Gritty Details
+## Details
 
-RubyGems.org app containers do not contain any vulnerable versions of `liblzma` nor `xz` (in addition to the fact that they run Alpine and thus were not vulnerable to the backdoor).
+RubyGems.org app containers do not contain any vulnerable versions of `liblzma` nor `xz`. In addition, they run Alpine which is not vulnerable to the backdoor.
 
 ```
 web-7b88594bd9-6g5nn:/app find / -name '*lzma*'
@@ -36,7 +36,7 @@ web-7b88594bd9-6g5nn:/app# find / -name '*xz*'
 /app/vendor/ruby/3.3.0/gems/bindata-2.5.0/lib/bindata/transform/xz.rb
 ```
 
-No ecosystem gems contain a vulnerable `liblzma.so`.
+As of March 31st 2024, no gems on RubyGems.org contain a vulnerable `liblzma.so`.
 
 ```irb
 irb(main):005> attrs = ['version_data_entries.full_name', 'rubygems.name',  'versions.number', 'versions.platform', 'versions.uploaded_at']