MIVEHIND

Notes From The Field 3

Tue, 25 Jun 2024 00:00:00 -0400

(This piece originally ran in Notes from the Field, a weekly column part of the main newsletter sent to Waltham Fields Community Farm CSA-holders. I was once again working in the fields.)

It is wonderful to be back on the farm. It feels both comforting and expansive: there is familiarity, but also new facets to learn, from meeting the new (awesome) folks in this year’s crew to learning the names of the fields which were in cover crop all last year. As we built up to the first harvests, it felt to me like the whole place was waking up. Plants becoming lush, and growing so large that covering them is a challenge. Warm (very warm) days, though I think we all could do without the heat of last week. Innumerable rabbits, and even a baby groundhog. And the birds.

Oh, the birds! The hawks have acquired enemies, small and agile, which harangue them in the skies. Beautiful yellow birds that we didn’t manage to identify. And the killdeer, perpetually hop-scurry away on their spindly legs. We have most contact with them, as they like to nest in empty beds, and produce a flurry of indignant chirping when we work nearby. In the peppers, ones nest contained four perfect speckled off-blue eggs - more field companions for the coming weeks. And today, while we staked tomatoes, the heron made a rare landing, huge and graceful. I get most excited, though, when the raven drops by. Huge and glossy, they radiate poise, fearlessness, and a fierce intelligence.

I’m write this while making dinner, and I’d be remiss not to mention that it contains two of my favorite farm-grown vegetables: kale and green garlic. The kale in particular is lush from the cover-cropping; it is neat to see such a strong difference result, To round out the top three, we harvested the last of the Napa cabbage for a while, which I will turn into sauerkraut. (For the curious, after cabbage the rest of my top ten is the various kinds of radishes we grow.)

On The Lineageos User Exposure Window

Sun, 07 Jan 2024 00:00:00 -0500

Unfortunate scheduling means that LineageOS users are exposed to publicly disclosed vulnerabilities for typically nine days per month. Here’s why, and what I (a user who is otherwise uninvolved in the project) think could be done to improve the situation.

Per official Android documentation:

Important: The Android Security Bulletins are published on the first Monday of each month unless that Monday falls on a holiday. If the first Monday of the month is a holiday the bulletins will be published on the following work day.

Holiday time off makes sense for human reasons, though it makes release days inconsistent. (And I assume we’re talking US holidays because Google, though this isn’t stated.) Adherence to this isn’t great - most egregiously, something happened that resulted in a March 13, 2023 release which is probably the largest slip since August 13, 2015 (which is far back as the table goes). But I’ve worked in security engineering long enough to know that sometimes dates will slip, and I’m sure it’s not intentional. Clerical errors like the November 2023 bulletin date are also inevitable.

But let’s assume for the sake of simplicity that disclosure happens as written: on the first Monday of the month (or the following day) a bulletin is published listing the CVEs included, their type/severity, and which Android (i.e., AOSP) versions are affected. Importantly absent here are the patches for these vulnerabilities, which per the bulletin boilerplate take 2 days to appear. So what’s the point of the bulletin?

In any case, this means that patches won’t be available until Wednesday or Thursday. Lineage posts updates on Friday; per datestamps, these updates are built on Thursdays. This means that in order to have the security fixes (and security string) in the next Lineage update, there is less than a day’s window to gather patches, backport them, post pull requests, run CI, get code review, etc., before the weekly build is made - a seemingly herculean feat. And sometime months, it won’t be technically possible at all.

So since patches will not land in the next release, all users of official builds are exposed to publicly disclosed vulnerabilities for typically nine days. (I think it’s 8-10, but I don’t discount off-by-one, and that also relies on Lineage not slipping further; everyone’s human and it does happen, especially on volunteer projects.)

Clearly, the schedule is a problem. Here are my initial thoughts on how this might be addressed:

Release Lineage updates on a different day. If it takes four days to run through the backport+review+build pipelines, then plan to release on Monday. Users will still be exposed for the length of time it takes to backport+review+build.
Add Lineage to the embargo list. This would mean that backport and review could take place prior to public disclosure, and so including the security fixes in the upcoming Friday update becomes doable. Users are still exposed for 2 days, but that’s way better than 9. (I am not involved in the Lineage project so it’s possible they already are included, but that seems unlikely given security update PRs are not usually sent on the day code becomes publicly available.)
Stop the bulletin/patch desync. I cannot come up with a good reason why the security bulletin and patches are released at different times, let alone releasing the bulletin before the patches. This makes reasoning about fix availability unnecessarily complicated. However, it would probably require Google to care.
Update Lineage less frequently. It seems like the least amount of work, but if, e.g., Lineage released once per month, then the day of the release could be whenever the security fixes for the month land. This is also helpful beccause it minimizes the number of times that flashing needs to occur. (But that may be a larger discussion for a different post.)

These are not mutually exclusive, either.

To close out, I need to head off something that I am quite sure will come up. Yes, I am capable of running my own custom Android builds and kernel trees. I do not want to do this, and more importantly, users who are not developers by definition cannot do it. That is to say: OTA updates and official builds are the most important versions of the project, not whatever custom stuff we make. (After all, if that weren’t the case, there wouldn’t be five major forks over the signature spoofing decision.)

Sourdough Boule

Mon, 24 Jul 2023 00:00:00 -0400

This is my weekly bread loaf that has evolved since mid-2018. Since I make it so regularly, its creation and general culture upkeep are intertwined. On an average week, it produces something like this:

I keep the culture at 100% hydration (i.e., equal mixture of flour and water by weight) solely because it simplifies the arithmetic of feeding. For similar reasons, I typically double the total size every feeding. Flour for most feedings is equal parts white and whole wheat, as it is more difficult for me to determine culture health when fed entirely whole wheat.

So, to start with, I remove ~110g of unfed culture from its home in the refrigerator. The remainder is fed, and placed back in the refrigerator. (If there is less than 100g remaining after feeding, it is instead kept warm and re-fed at 8-12 hour intervals until there is enough again.).

The 110g of culture is doubled: add 55g of water and 55g roughly equal parts white and whole wheat flour for a total of ~220g of goo (after mixing). At this point I cover it and go to work, so it won’t be touched for 10-12 hours.

Then, to the bubbly goo, I add 16g of salt, ~380g water, ~600g flour, and (depending on how things are feeling) 7g carraway seeds. I will regularly go up to 300g of the flour being whole wheat here: the more whole wheat used, the sooner the bread seems to become crumbly. It also affects how easy the dough is to work with, but not anywhere near as much as rye (which probably deserves its own post that it may or may not receive).

I mix that with a spoon until there are no dry flour clumps. Then, three times the dough sits for an hour and is folded. To fold, I first gather the dough in the bowl and flip it over, keeping it in the bowl. Then I grab an edge, stretch it as far as it will go without tearing, fold it back over the dough, and rotate 90°. I repeat the folding until it is no longer possible (except on the first attempt, where I usually get bored after 12 or so folds). Once done folding, I flip the dough ball back over, cover, and go back to waiting.

Once the three wait-and-fold cycles are done, the covered ball goes into the refrigerator for 24-48 hours and I go to bed.

When it is time to begin the baking process, first the ball is removed onto the counter for about 15 minutes in order to warm up. Typically I try to remove the larger air pockets here, but most shaping happens after it is warm. While waiting I dust the bottom of the dutch oven with cornmeal.

To shape, from the bottom, I push the edges of the ball inside itself. The goal is a taut but unbroken exterior surface, but it tastes just as good even if it rips. The ball goes seam side down into the dutch oven, which I cover and then let sit 2.5-3 hours.

After that, I set the oven to preheat at 475°F. While it does that, I lightly score the top of the ball (an X, unless creativity strikes) about 5mm deep. Scoring the is the step I am most likely to forget - the result is by no means ruined, but I find the texture less appealing.

Once preheated, I insert the covered dutch oven, and immediately drop the oven temperature setting to 425°F. It bakes like this for 45 minutes. Then I remove the cover and bake 10-15 minutes until it reaches the target color.

Then the bread is removed (hopefully easily) from the dutch oven onto a wire rack to cool “completely” (i.e., until I get bored of waiting and slice it). I have seen others recommend placing the loaf back on the oven rack itself to crisp, but I cannot recommend doing so here as that resulted in cornmeal on the bottom of the oven, which burned.

My personal preference is for day-old bread, so ideally I cover the cooled loaf with a towel and let it sit overnight before slicing. I have also determined that roommates are much more likely to eat bread that has been sliced rather than that which they need to slice for themselves. Letting it sit also makes it easier to create thinner slices - I target about 1cm.

Enjoy!

Notes From The Field 2

Tue, 20 Jun 2023 00:00:00 -0400

(This piece originally ran in Notes from the Field, a weekly column part of the main newsletter sent to Waltham Fields Community Farm CSA-holders. By this time I was working for the farm.)

Weeding is a funny thing. Fields are not cleanrooms, and no matter how many plants one pulls, there will always be more. There would be no harvest if it required growing only the desired plants and no others. Fortunately, such is not the goal: we need only encourage our chosen plants to outcompete.

From the perspective of a plant, to farm is to curate its surroundings until harvest. Plants are not machines, but we rely on them for transformation nonetheless: seed into leaves, dirt into vegetable. For me, there remains a sense of awe on seeing the seeds we planted become plants poking through the soil.

I have been thinking this week about the radishes. Planted at two different times, the younger has reached maturity first. Both are and will be delicious, of course - just not in the order they were planted. What made the difference between them? Was it different weeds, temperatures, location in the field? We can only speculate, and ask though I may, the radishes do not answer.

Notes From The Field 1

Tue, 11 Oct 2022 00:00:00 -0400

(This piece originally ran in Notes from the Field, a weekly column part of the main newsletter sent to Waltham Fields Community Farm CSA-holders. At the time, I was a volunteer and not employed as a farmer.)

This week, one of the crops we harvested was radishes. The process for harvesting radishes resembles that of many other crops: find and pull up a plant, check for quality, prune the foliage, gather the right number into a bundle, tie them off, and repeat. But when held by the stems, a bundle of radishes is floppy, making banding difficult. We chatted about technique while harvesting, and everyone has their own: for instance, some people hold the stems radish-down, perpendicular to the ground, while I have more success with a 45-degree angle. But then, we all make different tiny movements to complete a bundle, like catching the rubber band with the offhand thumb. When we become comfortable with an activity, the distance between the tool and our body vanishes, and instead of moving our hands to move objects, we move the objects directly. The tool, the radishes, the rubber bands: all become an extension of ourselves. And this complexity of action creates a banded bundle of beautiful vegetables, ready to be washed.

Against complacency, I have learned, is the phenomenon of “harvest creep”. When we as harvesters become comfortable with gathering bunches, the sizing of a bunch can almost be done by feel. This feel can be quite precise: I hear legend of folks able to pick up not only bundles of vegetables but even rubber bands and immediately know whether they are of the wrong size. And yet, the key is the “almost”, since as one harvests, the size of gathered bundles tends to “creep” up in size. In a way, I find harvest creep reassuring: avoiding it means our attention is a necessary part of the process. We are not rote actors, but rather overseers, active gatherers for this part of the cycle.

So in the field on Friday, we enjoyed perhaps one of the last warm days of the year. And we counted the radishes, just to be sure.

Shim Ab Booting Poc

Wed, 17 Aug 2022 00:00:00 -0400

I’ve implemented a proof-of-concept for “A/B booting” of shim itself. Concretely, this means that when a shim fails to boot, an older version will be tried as a fallback. This aims to increase the stability and reliability of shim updates. Booting the older shim is a stop-gap and not something we want systems to be regularly doing, so the situation is detected and reported for admin attention.

This is a proof-of-concept, and additional features/changes are not only possible but likely.

(“fallback” is a term with many meanings in this context, so we attempt to avoid its use.)

Trying it out

On Fedora rawhide, install this COPR:

dnf copr enable rharwood/shim-ab-enable
dnf update

This updates the shim packaging to be wired up with the A/B logic.

However, it doesn’t actually provide a second shim (the “B” part of “A/B”). Once the system is updated with the shim from the first COPR, install the second COPR:

dnf copr enable rharwood/shim-ab-second
dnf update

Now there are two versions of shim installed on the system.

Boot counting

Firmwares don’t operate on BLS entries, and so this looks different than boot counting at that level of the stack. However, in all cases the operation of recording when a boot succeeds lives in userspace (since the system must have booted). It is also possible to detect failures of the “A” loader that fall through to booting the “B” loader. In this proof-of-concept, the decision on what action to take is left to the admin, though it would be easy to script additional behavior.

This proof-of-concept implements both detections, logging results and a warning when the “A” loader has failed.

(To simulate “A” loader failure: remove or rename the shimx64.efi/shimaa64.efi files in the ESP and the latest /usr/lib/shim*, then reboot the system. Alternately, use efibootmgr to switch the order of primary and fallback.)

Technical details

The “A” shim uses the existing location in the ESP (e.g., \EFI\fedora\shimaa64.efi) and UEFI boot entry.

The “B” shim also lives in the ESP, and its name ends with _b (e.g., \EFI\fedora\shimaa64_b.efi). We do not think 8.3 names are required for these files. A new UEFI boot entry is created for it, currently called “Fedora fallback”, and placed immediately after the “A” entry (“Fedora”) in the boot order. This could be renamed to something else if that’s preferred.

On system update, the shims are rotated - that is, the old “A” shimx64.efi becomes the “B” shimx64_b.efi, and the new shimx64.efi is dropped into place. Because the same filenames are used, boot entries are not typically modified on update. It is therefore technically possible (though discouraged) to make an older shim the primary “A” boot target.

The shim files themselves are stored in /usr/lib/shim-ARCH-VERSION-RELEASE (where ARCH is the UEFI architecture name, like x64 or aa64). This allows userspace boot logging to determine which version of shim was booted, not just whether it was “A” or “B”. (It also allows reuse of these files without granting read access to the ESP or unpacking RPMs, which is a feature that has been requested elsewhere.)

Boot logging is kicked off by shim-booted.service, which is currently a requirement of multi-user.target. This runs a python script (shimctl) which logs to /var/log/shim_boots. The same script is also used for updating shims.

Secureboot Signing With Your Own Key

Thu, 12 May 2022 00:00:00 -0400

Create and enroll a key

First, we’ll need some packages:

dnf install pesign mokutil keyutils

(Package names are the same on most major distros, though of course your package manager won’t be the same.)

Next, we create a key for signing. This uses efikeygen, from the pesign project; I prefer efikeygen because it also creates an NSS database that will be useful for pesign later.

efikeygen -d /etc/pki/pesign -S -TYPE -c 'CN=Your Name Key' -n 'Custom Secureboot'

Replace Your Name Key with your name, and Custom Secureboot with a name for the key that you’ll remember for later steps. For -TYPE, replace with -m if you only plan to sign custom kernel modules, and -k otherwise.

(Note that this will set up the key for use in /etc/pki/pesign, which is convenient for pesign later, but it can also be placed elsewhere, like on a hardware token - see efikeygen(1) for more options.)

Next, export the public key and import it into the MOK (the Machine Owner Keystore - the list of keys trusted for signing):

certutil -d /etc/pki/pesign -n 'Custom Secureboot' -Lr > sb_cert.cer
mokutil --import sb_cert.cer

Again, replace Custom Secureboot the chosen name. mokutil will prompt you for a password - this will be used in a moment to import the key.

Reboot, and press any key to enter the mok manager. Use the up/down arow keys and enter to select “enroll mok”, then “view key”. If it’s the same key you generated earlier, continue, then “yes” to enroll. The mok manager will prompt you for the password from before - note that it will not be echoed (no dots, either). When finished, select reboot.

To check the key imported okay, we can use keyctl. Output could look something like this:

~# keyctl show %:.platform
Keyring
1072527305 ---lswrv      0     0  keyring: .platform
1013423757 ---lswrv      0     0   \_ asymmetric: Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53
 246036308 ---lswrv      0     0   \_ asymmetric: Your Name Key: 31fe6684706ff53faf26cec7e700f84aa0fd22ae
 919193603 ---lswrv      0     0   \_ asymmetric: Red Hat Secure Boot CA 5: cc6fa5e72868ba494e939bbd680b9144769a9f8f
 341707055 ---lswrv      0     0   \_ asymmetric: Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4

where the important part is that your key is among those listed. (The Microsoft keys are the “normal” anchors for secureboot, and the Red Hat one is present because this is a RHEL machine.)

Unenroll a key

If you want to unenroll a key you added, just do

mokutil --delete sb_cert.cer

This will prompt for the password, and reboot through mok manager as before, except this time select the option to delete the key.

Sign a kernel

Kernel signatures are part of the vmlinuz file. Unfortunately, the process differs between x64 (or amd64, or x86_64, or whatever you want to call it) and aarch64. First, x64 because it’s simpler:

pesign -c 'Custom Secureboot' -i vmlinuz-VERSION -s -o vmlinuz-VERSION.signed
pesign -S -i vmlinuz-VERSION.signed # check the signatures
mv vmlinuz-VERSION.signed vmlinuz-VERSION

Replace VERSION with whatever suffix your vmlinuz has, and Custom Secureboot with whatever name you chose earlier.

On aarch64/aa64, things are slightly more involved because the signature is pre-compression. Not to worry, though:

zcat vmlnuz-VERSION > vmlinux-VERSION
pesign -c 'Custom Secureboot -i vmlinux-VERSION -s -o vmlinux-VERSION.signed
pesign -S -i vmlinux-VERSION.signed # check signature
gzip -c vmlinux-VERSION.signed > vmlinuz-VERSION
rm vmlinux-VERSION*

Sign a kernel module

First, prerequisites - the signing tool. On Fedora/RHEL-likes:

dnf install kernel-devel

while on Debian-likes I believe this is part of linux-kbuild, and therefore pulled in by linux-headers.

The sigining tool uses openssl, so we need to extract the key from the NSS database:

pk12util -o sb_cert.p12 -n 'Custom Secureboot' -d /etc/pki/pesign

Replacing Custom Secureboot as before. This will prompt for a password, which will encrypt the private key - we’ll need this for the next step:

opensl pkcs12 -in sb_cert.p12 -out sb_cert.priv -nocerts -noenc

This is exporting an unencrypted private key, so of course handle with care :)

Signing will be something like:

/usr/src/kernels/$(uname -r)/scripts/sign-file sha256 sb_cert.priv sb_cert.cer my_module.ko

where my_module.ko is of course the module to be signed. Debian users will I think want a path more like /usr/lib/linux-kbuild-5.17/scripts/sign-file.

To inspect:

~# modinfo my_modile.ko | grep signer
  signer:         Your Name Key

where Your Name Key will be your name as entered during generation.

To test, insmod my_module.ko and to remove rmmod my_module.

Sign a grub build

This is fairly straightforward - the signatures live in the .efi files, which are just PE binaries, which live in /boot/efi/EFI/distro_name (e.g., /boot/efi/EFI/redhat).

pesign -i grubx64.efi -o grubx64.efi.signed -c 'Custom Secureboot' -s
pesign -i grubx64.efi.signed -S # check signatures
mv grubx64.efi.signed grubx64.efi

where Custom Secureboot is once again the name you picked above. Note that x64 is the architecture name in EFI - so if you’re on aarch64, it’d be aa64, etc..

Secure Boot Statements

Wed, 09 Mar 2022 00:00:00 -0500

I have said some things about secure boot and my involvement here.

I will try to say the same things monthly from here on out. The current plan is for them to appear dated in this folder.

That said, I am human and will probably forget sometimes. So while I encourage keeping an eye out for them, it’s probably best to reach out if I miss one and not worry too much unless several get missed.

Please remember that this only relates to what I do and what I know: it doesn’t include other distros, other parts of the supply chain, etc.. Other maintainers are encouraged to offer similar statements for their respective involvement.

(This statement, this post, and especially the encouragement for other maintainers to do the same originate from my co-worker pjones’s statement.)

Apple Extended Keyboard (m0115) Repair Teardown

Sun, 27 Feb 2022 00:00:00 -0500

I recently repaired an Apple Extended Keyboard (M0115). I took some pictures. This post is an excuse to show them. Repairs were successful, and I’m typing this post on it.

First, here’s the completed job:

This picture doesn’t capture the pronounced S-curve top-to-bottom that the keys are laid out on, nor how loud and pleasant it is to type on. It’s quite nice… once it works.

This will cause it not to work. I didn’t get from the previous owner what actually happened here, but my best guess from damage and residues (look at the ‘D’ keycap) is that a bottle of barbecue sauce fell on it from a great height. It takes quite a lot of force to snap the keycaps like that, and one of the internal struts as damaged too. It’s also positively filthy, but that might just be due to not being cleaned in 35 years.

What we’re working with. I needed to disassemble it for cleaning and repair, so let’s walk through that quickly. Reassembly is of course the reverse, and I’m going to use photos from that because no one needs to see the filth that was in here.

Four Philips screws on the bottom.

The case is additionally secured with clips. Some caution here is warranted - the case plastic is old and brittle. I release the top and two sides, then tip the whole thing forward, up, and out.

That exposes the inside. Two ADB connector boards on the top - careful when lifting these out. Set on a towel or some such, unless you hate your table.

To remove keycaps, we need to apply even upward force, distributed around the key.

That keypuller is two bent paperclips, because I hate my hands:

That takes care of the normal-width keys. The wider (or taller, in the case of keypad enter) keys have an additional stabilizer:

The metal slides into two brown U-shaped plastic pieces on the keycap, and there are two clips on the mounting board. For removal, I use a screwdriver to separate the metal from the board clips first to try to keep them attached to the mounting board - but if you’ve bought an “AS-IS” ebay item that the previous owner spilled soda on, they may come detached regardless.

This picture is the broken left shift key, hence the broken post. As a side note, the only difference I’ve seen between these keycaps and those of the Apple Extended II (M3501) is that the M3501 uses black clips, while these are brown.

All keycaps removed, post-cleaning. The caps lock keyswitch is locking, so it’s a different color. As you can see, I’ve removed the broken bits by this point, so here’s a close-up of while that was happening (pre-cleaning, so with filth):

Due to what broken when, you can see the stabilizer attachment for left shift in this picture too. All keyswitches survived undamaged, fortunately.

For cleaning, the keycaps were soaked overnight in soapy water. That actually takes care of most filth, but since I was there already (and it didn’t quite get everything), I did a toothbrush pass as well. One consequence of this is that the labels which had been added to various keys did not survive, so here’s a picture of them from before:

“PRINT Window / Screen” and “PAINT screen” eventually became Mac screen capture. On the numpad, these shortcuts are probably from Microsoft Word v1.06. The “Cut” / “Copy” / “Paste” on x, c, and v are interesting because they predate the ubiquity they now enjoy - the Apple Extended Keyboard’s upper case even preprints “undo cut copy paste” under F1 through F4. Finally, the Command key (which happens to be the one from the right) appears to say “MFinder” with a slash through it, which probably was to indicate that that the Mac OS 5-era MultiFinder multitasking was to be disabled on start. (“Switch screen” on 9 would be related to this as well.)

Fedora Has Too Many Security Bugs 3

Tue, 04 Jan 2022 00:00:00 -0500

(Previously part 2 and part 1.

Right now, there are 1917 open CVE bugs against Fedora. This is a decrease of 172 from last year - so again, we report good news. Gratitude toward maintainers who have been reducing their backlog.

Year breakdown:

While the bug that was last year’s tail (a 2009 bug) has disappeared, the tail is now much longer with the addition of the 2005 bug. The per-year deltas are:

2005: +1
2006: N/A
2007: N/A
2008: N/A
2009: -1
2010: N/A
2011: -1
2012: -5
2013: -1
2014: ±0
2015: ±0
2016: -1
2017: -25
2018: -26
2019: -35
2020: -390
2021: +302

(N/A is reported where neither last year’s run nor this year’s run had bugs in that year bucket, while ±0 indicates no change in the number year to year. The 2021 change is somewhat expected since there’s a lag between CVEs being assigned numbers and being disclosed.)

Unfortunately, the balance has shifted back toward EPEL: EPEL has 1035 of the 1917 total, a change of +77. This has outsized impact because EPEL is much smaller than non-EPEL Fedora.

For ecosystems, the largest ones I see are:

mingw: 99 (-41)
python: 95 (-14)
nodejs: 85 (-14)
rubygem: 20 (-7)
php: 13 (-6)

and it’s nice to see a reduction on all of them.

Finally, to close as before, there have been no changes to Fedora policy around security handling, nor is there a functioning Security Team at this time. Obviously no one should be forced into that role, but if anyone wants a pet project: the incentive structure here is still wrong.

For completeness, since bugzilla has changed a bit, here’s my script operating on the CSV file:

#!/usr/bin/python3

import csv
import re

from collections import defaultdict

with open("Bug List 2.csv", "r") as f:
    db = list(csv.DictReader(f))

print(f"total bugs: {len(db)}")

years = defaultdict(int)
r = re.compile(r"CVE-(\d{4})-")
for bug in db:
    match = r.search(bug["Summary  "])
    if match is None:
        continue
    year = match.group(1)
    years[year] += 1

for key in sorted(years.keys()):
    print(f"    {key}: {years[key]}")

epel = [bug for bug in db if bug["Product  "] == "Fedora EPEL"]

print(f"epel #: {len(epel)}")

components = defaultdict(int)
for bug in db:
    components[bug["Component  "]] += 1

# This spews - but uncomment to identify groups visually
# for c in sorted(components.keys()):
#     print(f"{c}: {components[c]}")

def ecosystem(e: str) -> int:
    count = 0
    for c in components:
        if c.startswith(f"{e}-"):
            count += components[c]
    return count

print(f"mingw ecosystem: {ecosystem('mingw')}")
print(f"python ecosystem: {ecosystem('python')}")
print(f"nodejs ecosystem: {ecosystem('nodejs')}")
print(f"rubygem ecosystem: {ecosystem('rubygem')}")
print(f"php ecosystem: {ecosystem('php')}")