5 ms·

Public facing? Handles user input data?? Uses ‘eval’???

Gigachad 5y ago
The line existed in the 2014 commit which migrated the repo to git. It wasn't designed in the current era of mass automated abuse and internet connected everything.
- majou 5y ago
  2014 was very much that era, I'd accept this excuse maybe for 2007
  - kibwen 5y ago
    The line wasn't written in 2014, that's just the earliest that the history goes back. Presumably it's no newer than the early 2000s.
    - Gigachad 5y ago
      Considering that initial commit contains 400k lines, I would say there is a very long history before git was used.
  - danudey 5y ago
    I remember before 2007 seeing people using eval and thinking "what on earth is wrong with you?" I'd accept this for maybe pre-2000, but people should really know better.
  - leejo 5y ago
    The comment in the code slightly above says: this doesn't work in perl 5.6.2! grrrr So this code is at least 20 years old, and probably pre-2000.
    - sebcat 5y ago
      https://exiftool.org/ancient_history.html https://exiftool.org/ancient_history.html Sept. 26, 2008 - Version 7.44 - Added read support for DjVu images There were probably enough systems running perl 5.6.2 around 2008 to cause bug reports, or the code was migrated from an older piece of code and added to ExifTool. It was not uncommon to manually ./configure, make, make install tarballs locally in those days, especially not on systems like Slackware so I can see it being possible to have old packages installed that were not automagically updated.
- smashed 5y ago
  That line is in a Perl metadata cleaning library. Not in Gitlab itself. Gitlab, who prides themselves and sell the gospel of improving security, willfully chose to use that library which was obviously never designed for their use case. I looked at the front-page of that library. It says it cleans metadata from a huge number of file format. Frankly it looks more like something you would use on your own, known safe, files before sharing them online. I'm not sure the tool is presented as a sanitizer for untrusted input. At least, it does not claim to be. Why does Gitlab need to clean metadata from DjVu files? Wtf are DjVu files?!
  - tingletech 5y ago
    I think they are like a very old version of jpeg 2000s that support pan and zoom / tiling of large image files. It needed a license to create and one to display iirc
  - jorams 5y ago
    > Why does Gitlab need to clean metadata from DjVu files? It doesn't. It needs to clean metadata from JPEG and TIFF files. They didn't properly check if the files were actually of those types, and Exiftool performed its own content type detection to end up in its DjVu code. > Wtf are DjVu files?! DjVu is basically an alternative to PDF.[1] [1]: https://en.wikipedia.org/wiki/DjVu https://en.wikipedia.org/wiki/DjVu

The line existed in the 2014 commit which migrated the repo to git. It wasn't designed in the current era of mass automated abuse and internet connected everything.

majou 5y ago
2014 was very much that era, I'd accept this excuse maybe for 2007
- kibwen 5y ago
  The line wasn't written in 2014, that's just the earliest that the history goes back. Presumably it's no newer than the early 2000s.
  - Gigachad 5y ago
    Considering that initial commit contains 400k lines, I would say there is a very long history before git was used.
- danudey 5y ago
  I remember before 2007 seeing people using eval and thinking "what on earth is wrong with you?" I'd accept this for maybe pre-2000, but people should really know better.
- leejo 5y ago
  The comment in the code slightly above says: this doesn't work in perl 5.6.2! grrrr So this code is at least 20 years old, and probably pre-2000.
  - sebcat 5y ago
    https://exiftool.org/ancient_history.html https://exiftool.org/ancient_history.html Sept. 26, 2008 - Version 7.44 - Added read support for DjVu images There were probably enough systems running perl 5.6.2 around 2008 to cause bug reports, or the code was migrated from an older piece of code and added to ExifTool. It was not uncommon to manually ./configure, make, make install tarballs locally in those days, especially not on systems like Slackware so I can see it being possible to have old packages installed that were not automagically updated.
smashed 5y ago
That line is in a Perl metadata cleaning library. Not in Gitlab itself. Gitlab, who prides themselves and sell the gospel of improving security, willfully chose to use that library which was obviously never designed for their use case. I looked at the front-page of that library. It says it cleans metadata from a huge number of file format. Frankly it looks more like something you would use on your own, known safe, files before sharing them online. I'm not sure the tool is presented as a sanitizer for untrusted input. At least, it does not claim to be. Why does Gitlab need to clean metadata from DjVu files? Wtf are DjVu files?!
- tingletech 5y ago
  I think they are like a very old version of jpeg 2000s that support pan and zoom / tiling of large image files. It needed a license to create and one to display iirc
- jorams 5y ago
  > Why does Gitlab need to clean metadata from DjVu files? It doesn't. It needs to clean metadata from JPEG and TIFF files. They didn't properly check if the files were actually of those types, and Exiftool performed its own content type detection to end up in its DjVu code. > Wtf are DjVu files?! DjVu is basically an alternative to PDF.[1] [1]: https://en.wikipedia.org/wiki/DjVu https://en.wikipedia.org/wiki/DjVu