Corresponding news story: https://www.dailydot.com/debug/no-fly-list-us-tsa-unprotecte...
>[...] the vast majority of people who have disputed travel and appeal to the Department of Homeland Security’s Traveler Redress Inquiry Program are not on the terrorist watchlist. Most people on the terrorist watchlist are still able to fly within the U.S. A very small subset of people on this list are on the “No Fly” list.
[...]
>The No Fly List is a small subset of the U.S. government Terrorist Screening Database (also known as the terrorist watchlist) that contains the identity information of known or suspected terrorists. This database is maintained by the FBI’s Terrorist Screening Center.
So, shouldn't this list be public information anyway? It's not even suspicious people they're watching, by the sound of it the no fly list is only for people they have concrete evidence of terrorist activity for. Imo the public has a right to know those identities.
[1]: https://alunr.com/excel-csv-import-returns-an-sylk-file-form...
A,B,Alice "Mallory" Bob,123Some planning, some building out new stuff (usually clean work), some repairing active geysers of partially processed data that's getting all over the place fouling up the works.
So the following Excel export I just did will parse perfect fine with your CSV parser but give you completely the wrong thing:
1;2,3;3,3
2;7,3;9,3
3;4,5;7,5“The CSV file format is not fully standardized. Separating fields with commas is the foundation, but commas in the data or embedded line breaks have to be handled specially. Some implementations disallow such content while others surround the field with quotation marks, which yet again creates the need for escaping if quotation marks are present in the data.
The term "CSV" also denotes several closely-related delimiter-separated formats that use other field delimiters such as semicolons.[2] These include tab-separated values and space-separated values. A delimiter guaranteed not to be part of the data greatly simplifies parsing.
Alternative delimiter-separated files are often given a ".csv" extension despite the use of a non-comma field separator. This loose terminology can cause problems in data exchange. Many applications that accept CSV files have options to select the delimiter character and the quotation character. Semicolons are often used instead of commas in many European locales in order to use the comma as the decimal separator and, possibly, the period as a decimal grouping character.”
https://en.wikipedia.org/wiki/Comma-separated_values#Standar... mentions a few standards for csv, one of which is the MIME type text/csv, standardized in RFC 4180.
But that doesn't extend to using backslash escapes in something that's legitimately trying to be CSV. That's someone getting confused and implementing a mix of data formats, or trying to be clever and making an extended CSV format.
That, in turn, means you almost cannot use CSV in any robust solution. Even if, today, your input doesn’t have commas, quotes or newlines, can you guarantee it won’t tomorrow, next year, etc?
But... but those are the ones I listed as real special characters, unlike backslash. I don't understand the question.
There were also prod AWS credentials in the files exposed in Jenkins.
But then, I am not a Bond-esque criminal organization bent for world domination.
At the very least, I don't think the company was operating like every random developer should have full-access to the no-fly list, which is what they de-facto gave them when they dumped an old copy into the test pipeline.