[HN Gopher] Information on the revocation of WinRAR 5.91 digital...
___________________________________________________________________
Information on the revocation of WinRAR 5.91 digital certificate
Author : Bastich
Score : 127 points
Date : 2020-08-26 16:15 UTC (6 hours ago)
(HTM) web link (www.rarlab.com)
(TXT) w3m dump (www.rarlab.com)
| Jerry2 wrote:
| Anyone know which CA did this? I'd like to add it to my list of
| 'entities to avoid doing business with'.
| gruez wrote:
| https://news.ycombinator.com/item?id=24284425
| gruez wrote:
| The CA in question is CN = Sectigo RSA Code Signing CA
| tgsovlerkhgsel wrote:
| This is the most important information in this. Other people
| who are looking for code signing certificates should use this
| information to choose their CA.
|
| From the view of the certificate holder, the CA has one job:
| Keep their certificate valid. Everything else (including the
| trustworthiness of the CA, e.g. whether they issue false
| certificates) only matters insofar as it affects that job (if
| the CA were to screw up up badly enough to get removed from
| certificate stores, the certificate also becomes invalid, but
| other than that, the certificate holder doesn't really care how
| the CA acts).
|
| By relying on a CA known to take such action (whether justified
| or unjustified), you're putting the continued usability of your
| software at risk, i.e. there is a strong reason to pick any
| other trusted CA.
| garaetjjte wrote:
| ...previously known as Comodo. Did their reputation was so bad
| that they had to rebrand?
|
| https://sectigo.com/resource-library/comodo-ca-is-now-sectig...
| sedatk wrote:
| Yes they've been pretty much terrible. https://www.techdirt.c
| om/articles/20160623/17483934805/super...
| breakfastduck wrote:
| I know the authorities need to err on the side of caution, but
| it's quite astonishing to me that someone at the authority didn't
| just say 'It's WinRAR...' and let it slide.
|
| It's got to be one of the most well known tools in the entire
| windows ecosystem.
| LorenPechtel wrote:
| If it were just the file not being clean on Virustotal I would
| fully agree. Heuristic detection will result in false
| positives. However, if they had an actual example of malware
| signed by that key that would indicate a compromise and that
| would justify pulling it. The absence of the offending file is
| suspicious, though.
| luckylion wrote:
| If they had an example, they would've never deleted it
| though. I mean, that part is so unprofessional, it's rude to
| believe are that incompetent, the polite explanation is that
| they lied about it.
| breakfastduck wrote:
| Yep, it would certainly justify pulling it, but quite bizarre
| that they're then refusing to issue another certification -
| I'm sure the WinRAR team would be able to prove they're the
| genuine developers.
| wnevets wrote:
| This CA sounds kinda incompetent. Even if you ignore the fact
| who winrar is, just the nature of the tool itself makes its
| silly to use virustotal as the gatekeeper.
| monoideism wrote:
| They should really name the CA. It's quite common for 1 of the 60
| tests on virustotal.com to turn up a false positive.
| sedatk wrote:
| https://news.ycombinator.com/item?id=24284425
| Santosh83 wrote:
| It is particularly ironic that so many people in this thread are
| recommending 7-zip in response to a cert problem with WinRAR when
| 7-zip has no code signing at all and presents the scary yellow
| "unknown software" screen when you try to install it.
| Arnavion wrote:
| The scary yellow screen that everyone clicks through anyway. I
| don't think 7zip needs to worry about that harming its
| adoption.
|
| Codesigning is a protection racket, and FOSS should not feel
| pressured to participate in it.
| dependenttypes wrote:
| People are not recommending 7-zip in response to the cert
| problem but rather to someone directly asking for a superior
| alternative in https://news.ycombinator.com/item?id=24284253
|
| Regardless, 7zip does not have as much of a need for a
| certificate because it is foss so you do not need to trust the
| creators, in comparison to winrar which isn't and you need to
| trust them.
| rgj wrote:
| The fact that it is FOSS makes it _easier_ for someone to
| compile it with a backdoor or trojan. I would say the need
| for a certificate is _higher_ there. You don't need to trust
| the developers, you need to be able to trust the people who
| have built the executable.
| GuB-42 wrote:
| I didn't even realize that the "scary" yellow prompt was
| related to code signing. For me it was just what happens when
| you run an executable from the internet.
|
| Do anyone pays attention to this? There is a lot of legitimate
| software you can't install without clicking through. 7-zip is
| just one of them.
| yjftsjthsd-h wrote:
| It's a bit like the way that plaintext HTTP is way easier to
| deal with than HTTPS, and the way browsers treat a self-signed
| cert as worse than no cert. Which... does lead to some _odd_
| outcomes, yes.
| xacky wrote:
| With both Windows and MacOS both putting scary warnings and hard
| to bypass blocking methods on improperly signed software this
| could eventually lead to developers being ransomed, "pay us big
| money or we will revoke your certificate". This is not the only
| incident like this.
| renewiltord wrote:
| A non-problem. Linux will run on x86 hardware till the end of
| time.
| kube-system wrote:
| Professional developers have to write code that runs on their
| customers' systems.
| renewiltord wrote:
| The customers have a VM for this that will be likely
| delivered indefinitely for this purpose: Webkit + friends.
| t0mas88 wrote:
| That would also be possible for a successful website or app
| using pinning. So far there are no public reports of it
| happening.
|
| Would probably also put the CA out of business in no time if
| they did.
| joshspankit wrote:
| _For now_.
|
| It's very easy to see two steps ahead on this
| gruez wrote:
| >this could eventually lead to developers being ransomed, "pay
| us big money or we will revoke your certificate"
|
| by whom? the platform makers (apple/microsoft) or malicious
| third parties?
| phreack wrote:
| Apple is effectively doing this to Epic and others, but it
| could be done by any agreement of enough CA's as well.
| EricE wrote:
| Epic violated the agreements they signed with Apple.
|
| Whether or not we care for the contents of the agreements
| is a separate issue. Apple did not capriciously act against
| Epic - if they had then Epic wouldn't have had an
| advertising campaign and lawsuit ready to go within hours.
|
| The situation with WinRAR is completely different and it
| doesn't help anything in trying to conflate the two; indeed
| it just muddies the waters :(
| joshspankit wrote:
| I'd argue that it's more similar than it seems, but with
| one caveat: Apple (rightfully) became the market leader,
| but is essentially running what should be a public
| market.
|
| If one company took over all the physical land on the
| planet, and had everyone sign agreements to essentially
| pay taxes to them with every transaction, would we still
| argue that that's not only legal, but morally justified?
| izacus wrote:
| Both. We've seen third parties do this on Windows and Apple
| themselves use this to punish developers who dared criticize
| them.
| Karunamon wrote:
| Where and when did Microsoft or Apple yank someone's
| developer cert for the sole reason of criticism? An
| accusation that serious needs to be substantiated.
| cosmotic wrote:
| The winrar trial has ads in it that try to load activex controls
| using embedded IE webview; an obvious security concern. I
| reported it and they suggested I enable activex.
| _jal wrote:
| Who was the CA with whom they had this difference of opinion?
| sedatk wrote:
| https://news.ycombinator.com/item?id=24284425
| batch12 wrote:
| Weird. Though there would be value in working with the vendors
| backing VT to get this fixed as this is just one of the issues
| with a false positive. Another is that users who use these
| products are probably alerted or otherwise prevented from using
| WinRAR too.
|
| VT has it as malicious with the new hash too [1] .
|
| Antiy-AVL calls it Win32.Shelma. Only good definition that seems
| to match that detection is from Kaspersky [2] stating that the 64
| bit version is detected as using metasploit [3] components.
|
| [1]
| https://www.virustotal.com/gui/file/21dd688a5371f5b0d297a307...
|
| [2] https://threats.kaspersky.com/en/threat/Trojan.Win64.Shelma/
|
| [3] https://www.metasploit.com/
|
| edited: formatting
| cm2187 wrote:
| I would have incremented the version number so the likes of
| Chocolatey would pick it up and replace the version installed
| with a revoked certificate as part of a regular update.
| toast0 wrote:
| I agree; the .exe is different (because the
| signature/certificate is embedded), so it should be a different
| version number.
| black3r wrote:
| Do people still use WinRar? :O
| Arnavion wrote:
| Yes. People who don't know any better alternatives continue to
| use it, and continue to recommend it to other people. So the
| cycle continues.
|
| Heck, WinZip still makes new releases so I'm sure people still
| use that too.
| AlexandrB wrote:
| > People who don't know any better alternatives continue to
| use it
|
| Genuine question: what are the better alternatives?
| saxonww wrote:
| For zip files in particular, you can just right click and
| 'Extract all' in modern versions of Windows. I believe you
| can also double-click to open them like folders in
| Explorer.
|
| 7-Zip covers the majority of other formats you're likely to
| encounter.
| geogra4 wrote:
| 7zip
| Semaphor wrote:
| I haven't used WinRAR in ages, but what makes 7zip (which
| I use as well) better?
| olvy0 wrote:
| It can extract files to paths of more than 260
| characters, without any extra tools or registry hacks, on
| any version of windows (even xp). Winrar cannot. As a
| bonus, 7zip can also delete folders with file paths that
| are over 260 characters from its file manager ui. It has
| been one of the only programs to be able to do so for
| many years.
| Seanambers wrote:
| Amount of times this has been an issue with using Winrar
| for 15+ years : zero.
|
| I'm amazed at all the comments calling for 7zip as the
| one and only. winrar works just fine so does windows zip
| function. If you have an edge case, yeah then you need
| something that can handle it.
| olyjohn wrote:
| WinRAR works fine. But it's $29. 7zip works fine and is
| not $29.
| greatgib wrote:
| 7zip is completely free and OpenSource, and more modern.
|
| I think that they also support more archive formats and
| they even have their own open format 7z.
|
| Based on their own claims, there are also faster and more
| efficient than Winrar.
| breakfastduck wrote:
| Yep, +1 for 7zip
| PrimeDirective wrote:
| 7zip (the archive manager, not the compression format), at
| least for Windows
| pbalau wrote:
| TotalCommander.
| theandrewbailey wrote:
| Peazip: https://peazip.github.io/
|
| I used to use 7zip, but switched when I discovered that
| Peazip doesn't extract to a temporary directory when
| extracting (thus, saving extra I/O work). It directly
| extracts into the target directory.
| jasperry wrote:
| In response to WayToDoor, some archives contain thousands
| of files, and it's essentially doubling the number of
| filesystem operations by putting them in a temp directory
| and then moving. If the temp directory is on a different
| drive from the destination, then it's recopying all the
| data.
|
| I thought the creation of the files in the temp directory
| was an unavoidable artifact of how drag-and-drop worked
| in Windows. If peazip can get around this, I might check
| it out.
| ta89764894 wrote:
| Avoiding a temp directories is usually a good thing,
| unless the temp directory allows you to avoid operations
| on removable drives. I've noticed on windows with drives
| marked as "removable" it's almost always faster to copy
| an archive to the harddrive (non-removable drive) extract
| it and copy the contents back. I'm assuming this is
| because of the different or lack of caching available for
| removable drives. Random read/write is typically a lot
| slower that sequential read/write so an ideal solution
| would take into account the relative performance of
| different drives before with making or not making a temp
| folder.
| WayToDoor wrote:
| Is a file move that big of an IO operation?
| sumtechguy wrote:
| depends on the move operation. 1 file you would not
| notice it. Thousands it would add up. Across 2 physical
| drives you may also notice it if the file is big enough.
| vore wrote:
| I run into the issue sometimes cross-volume, where the
| file gets extracted into a temporary directory then has
| to be copied to the actual destination, into e.g. a
| network volume or second hard disk.
| theandrewbailey wrote:
| Back when I used Winzip/7zip, they didn't move files:
| they copied files. When you're working with files
| measured in gigabytes, the speedup is quite noticeable.
| iMerNibor wrote:
| If it's moving it to a different drive/partition it'll
| have to copy it again
|
| Moving many (small) files can also be quite slow
| mrweasel wrote:
| Or maybe their customers just like the product, as in the GUI
| and feature and don't care that another compression algorithm
| can shave off a few extra megabytes.
|
| If I recall correctly WinRAR can make self extracting
| archives pretty easily. If you use that feature it might be
| easier/better to just continue using WinRAR.
|
| I love the fact that small software companies like RARLAB can
| still exist.
| breakfastduck wrote:
| It would be incredibly sad to see them go out of business,
| it's such an iconic piece of software.
| yjftsjthsd-h wrote:
| > It would be incredibly sad to see them go out of
| business, it's such an iconic piece of software.
|
| Granted, it's also famous for (supposedly) nobody ever
| paying for it, which doesn't exactly lend itself to
| staying in business.
| breakfastduck wrote:
| That's true, but considering how widespread the software
| is, it's likely that they only need a tiny percentage of
| the overall user-base to pay to remain a sustainable
| business.
|
| They could at any point have changed the software to
| prevent it from functioning after the trial has expired -
| they're not going to be so naive to think people will all
| pay just because of a prompt that can be easily
| dismissed.
| garaetjjte wrote:
| I wonder how profitable they are. In Poland WinRAR was big
| at the time (still sort of is, but 7-zip taken over a lot
| of users), but buying license was actually point of jokes
| and memes. Everybody just used shareware trial and closed
| that nag window every time.
| olyjohn wrote:
| We paid for an enterprise license for like 5000 computers.
| Why the fuck we did that, nobody seems to know.
| Arnavion wrote:
| > Or maybe their customers just like the product, as in the
| GUI and feature and don't care that another compression
| algorithm can shave off a few extra megabytes.
|
| First of all, I very much doubt that the people who use
| winrar even notice the UI. They could switch to 7zip and
| feel right at home. People are used to UI changing
| drastically all the time, both from Windows itself, and
| from websites. Some of them complain about it, but even
| they adjust.
|
| Second, I said nothing about "another compression
| algorithm". All the big compression software on Windows
| support each other's algorithms, but 7zip is free and
| winrar makes you pay for it. Also the people who use winrar
| don't care about compression algorithms in the first place,
| only that they get a file they can email and the other
| people can double-click to extract.
|
| Third, the reality of the situation is that most people who
| use winrar are also the kind that use the trial version
| indefinitely. The more clued ones switch to pirated copies
| from piratebay et al. I'd rather people use 7zip than
| pirated copies, both for their safety _and_ for RARLAB 's
| benefit.
|
| The reason these companies charge for things that are free
| is because they rely on users not knowing better, and the
| small fraction of users who do pay for it is sufficient to
| bankroll them. A 7zip user and a winrar user could be
| friends for life and the topic of "So what compression
| software do you use?" might never come up.
|
| >If I recall correctly WinRAR can make self extracting
| archives pretty easily.
|
| So can 7zip.
|
| >I love the fact that small software companies like RARLAB
| can still exist.
|
| You say this as if the alternatives are all big software
| companies. Last I checked, 7zip is still a one-person
| software.
| theandrewbailey wrote:
| WinRAR seems to have added additional compression formats
| and algorithms, like 7zip and XZ:
| https://www.rarlab.com/otherfmt.htm
|
| WinZIP, too: https://www.winzip.com/win/en/lanall.html
| wheybags wrote:
| I have found that some multipart rar files fail to extract
| properly with 7zip. Most are fine though, but I normally have
| the unrar-nonfree package installed for the few that don't
| work.
| XzetaU8 wrote:
| Had a similar issue with some rar files but the latest
| v20.02 seems to have solved it and everything work fine so
| far, also if you want try to report this issue on their
| forum.
|
| https://sourceforge.net/p/sevenzip/discussion/45797/thread/
| 9...
| vbezhenar wrote:
| What is better alternative? 7-zip UI is not as good and
| missing some WinRAR features.
| MikusR wrote:
| There are alternatives with built in recovery records? Which
| ones? I am being serious.
| mmebane wrote:
| That's the single remaining killer feature of RAR for me. I
| think the last time I actually used it was years ago when
| pulling a backup off of a degraded DVD-R, but it still
| provides a bit of peace of mind for long-term storage.
| tclancy wrote:
| Hang on, should I be moving off of pkzip?
| hinkley wrote:
| Somehow archival tools have become political. 7zip seems to
| be the new one people use even though that means their users
| now have to download and understand two packages instead of
| one. It's off-putting, especially when downloading your tool
| was already an act of yak shaving. As awesome as we want to
| think our tools are, the people who use them may be
| preoccupied with other problems instead. Friction will not
| convert them.
|
| I think I shamed someone out of using 7z recently by pointing
| out that if they claim to be trying to attract a broad
| audience of hobbyist developers, using a compression library
| that doesn't exist on OS X (with out without Xcode) is not a
| smart plan. In this particular case you had to download two
| tools to use their code, and that just tore it for me.
|
| When I went back recently they had switched to .xz, which
| does exist.
| edgarvaldes wrote:
| I have used both and prefer the WinRar GUI and the better
| multi part support.
| Stevvo wrote:
| WinRAR does everything you ask of it; compress or decompress
| archives in one click. Why wouldn't people still use it?
| spoopyskelly wrote:
| Because every operating system has built in zip compression
| support.
| parliament32 wrote:
| WinRAR is for RAR files, as the name suggests.
| Karunamon wrote:
| zip is hardly the only compression algorithm, or the best
| one for all conceivable use cases, and tools like Winrar
| (and 7zip, for that matter) offer additional features that
| the OS tools do not.
| inetsee wrote:
| Ebooks available on IRC are often compressed as RAR files. More
| often lately Epub books are not being compressed since Epub
| files are already compressed, and compressing them again as RAR
| files doesn't really gain you anything.
| pletnes wrote:
| I ask the same. It also has bugs where a zip/unzip roundtrip
| yields a different file. Not good.
| jug wrote:
| I do use 7-zip myself, but WinRAR has still a more feature rich
| user interface out of the box than 7-zip and while 7-zip has
| better compression in general, compression isn't everything
| when they're this close to each other, like a few percents
| different ratio.
| ikeboy wrote:
| Not a lawyer but I suspect there's a viable tortious interference
| claim. Revocation is effectively telling your customers that your
| product is unsafe, if done without cause it could be actionable.
| gruez wrote:
| >Revocation is effectively telling your customers that your
| product is unsafe
|
| ...or that the certificate was no longer in compliance with
| their Certificate Practice Statement. It looks like their CPS
| gives them a great deal of leeway here.
| https://sectigo.com/uploads/files/Sectigo-CPS-v5.2.pdf#page=...
| ikeboy wrote:
| The main clauses either require a reasonable belief, which is
| a factual question that could easily go against the CA, or
| says they need to be "identified" as publishers of malicious
| software, without specifying how. An antivirus site that has
| many false positives likely wouldn't qualify.
| pimterry wrote:
| > We think that revoking certificates based on questionable data
| discredits the certification system.
|
| It's hard to dispute this imo. There are many good reasons
| certificates should be revoked, but the reasoning should be 100%
| public information, for both the vendor and users who may have
| trusted the original certificate.
|
| I'm building a desktop app, and the process to even get a
| certificate is absurd. Each CA has their own wildly different
| processes, and seemingly answers to nobody. I changed cert
| providers recently after Digicert suddenly raised their prices
| 400% on a whim, and it took a huge number of changing
| requirements, phone calls, 3rd parties, and over a month to
| receive the new one, despite already having an existing verified
| & still-valid signing certificate with all those details from an
| equally legitimate provider.
|
| I'd kill to see a modern service a la Let's Encrypt but for code
| signing. Something transparent, reliable, fast & trusted cross-
| platform (I can dream). Verifying identity is a hard problem, but
| it's really not _that_ hard a problem - there's plenty of fintech
| services that can reliably do sufficient KYC for banking in 5
| minutes with a few id details and video call.
| asdfasgasdgasdg wrote:
| There's another aspect of this situation that also discredits
| the system: that they can just go out and get a different cert
| from another vendor. How many such vendors are there? How long
| would it take for an actual bad actor to have all their certs
| discovered and revoked? If that time is long, then the
| certification process is of even more dubious value, since the
| bad guys would not be materially hindered by the certification
| requirement.
| tgsovlerkhgsel wrote:
| The job of a certificate authority is to verify an identity,
| not to vet that the holder is using the certificate only for
| good.
|
| As long as the CAs do that job (which is a separate issue),
| it's fine if John Doe can get 50 different CAs to certify
| that he is, indeed, John Doe.
| asdfasgasdgasdg wrote:
| Plainly whoever is issuing the cert we're discussing sees
| their role as much broader. Presumably the OS manufacturer
| also sees it that way.
| gruez wrote:
| "Security-in-depth":
| https://news.ycombinator.com/item?id=24193087
| asdfasgasdgasdg wrote:
| On some level I get it but aren't cash cards a thing? What
| actual level of identity and KYC do these cert companies
| do? How easy is it for someone without scruples to get
| another cert without revealing their identity? (Genuine
| questions: I do not personally know.)
| deburr wrote:
| Cash cards can be distinguished against at the merchant
| level by most payment providers (and often are to prevent
| delayed charge fraud).
| AnthonyMouse wrote:
| The other consideration is that verifying identity is
| _pointless_ , because malware authors don't actually use their
| own identities, they just pull a code signing certificate from
| the 1% of their already-infected users who have one. Then they
| go out and infect a million more users with it and get 10,000
| more code signing certificates.
|
| If all you're after is some kind of rate limiting then forget
| about identity verification and just require proof of a unique
| $500 donation to a 501(c)(3). Not only would it be easier to
| automate, it would do some good in the world, and people would
| be a lot happier to see their resources go there than to some
| box checking bureaucrats.
| DaiPlusPlus wrote:
| This is why code-signing certificates must be two-factor
| (e.g. embedded on a PIN secured smartcard where the private-
| key is protected from extraction by _anybody_ ).
|
| My Tucows certificate is still a single *.pfx file - whereas
| my arguably less-consequential AATL (Adobe PDF signing)
| certificate is stuck on a crappy USB device that requires me
| to install marketing-laden software for. I miss my old
| commodity smartcard-based certificates.
| gnu8 wrote:
| That doesn't rate limit wealthy attackers, it just locks
| regular individuals out of the system. Peter Thiel could
| still buy 10,000 malicious certificates at $500/ea, while I
| wouldn't even be able to buy one for a simple project.
| MadVikingGod wrote:
| Let's Encrypt's argument for why all the fancy features that
| CA's offered boiled down to "These are more complicated ways of
| proving that you own a domain". So by automating the
| verification of ownership of a domain you could essentially run
| a CA for pennies per certificate, and give them out for free.
|
| Looking at application development I think a similar thing
| could be done, but what would we pin identity to? I don't know
| if there is one thing that every app has like a website.
| DaiPlusPlus wrote:
| Registered company information and/or notarised identity
| cards.
| benlivengood wrote:
| > Looking at application development I think a similar thing
| could be done, but what would we pin identity to?
|
| How about domain name?
|
| Whenever I install (Windows) software I rarely care about the
| mailing address or D.B.A. name; I look at the website address
| listed.
| batch12 wrote:
| I agree that it would be nice to have a letsencrypt for code.
| The biggest hurdle I see is getting the the root trusted by OS
| vendors. While not impossible (the browser vendors did it),
| trust on these platforms may be a bigger issue since the code
| runs natively.
| akersten wrote:
| > another explanation, i.e. that one reason for the revocation is
| some mysterious 570 MB executable file, which had been signed
| with our certificate but looked like a file used by hackers.
|
| Woah, talk about burying the lede? This sentence makes it sound
| like their private key was compromised, in which case it makes
| total sense to revoke the cert. Unless I'm misunderstanding what
| they're trying to say here.
| skymt wrote:
| You are misunderstanding. WinRAR's implication is that the CA
| is lying about the 570 MB file because they didn't mention it
| until WinRAR challenged them on the VirusTotal justification
| for revocation, and because they were unable to provide the
| file in question or any evidence that it exists.
| londons_explore wrote:
| Why not at least link to the virustotal listing for said
| file? Perhaps someone else has it from the hash?
|
| I doubt the CA would lie about the existence of such a file,
| although perhaps they are mistaken about the signature (it
| could be a case of a 570 MB file concatenated with a
| legitimately signed winrar executable - signatures don't
| always cover all parts of the file)
| ivank wrote:
| > Why not at least link to the virustotal listing for said
| file?
|
| I don't think virustotal accepts files larger than 500 MB.
| tgsovlerkhgsel wrote:
| It seems unlikely it's on VT:
|
| 1. VT has an upload limit of 128 MB. (Maybe the private API
| allows more, not sure.)
|
| 2. VT allows sample download if you have a VT Intelligence
| account - so if this was a file shared with VT, the CA
| should be able to provide the file.
| gruez wrote:
| [deleted]
| skymt wrote:
| The WinRAR post doesn't say that the file was submitted to
| VirusTotal, only that the CA said it "looked like a file
| used by hackers". Either there was no VirusTotal record for
| it or there was and WinRAR omitted that fact because it
| weakened their argument.
| qtplatypus wrote:
| Also this file (if it existed) was used to justify a
| business critical decision. Why wasn't there a paper
| trail for this file. Why wasn't this data archived?
___________________________________________________________________
(page generated 2020-08-26 23:01 UTC)