View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
519	[file] General	minor	always	2024-04-25 13:46	2024-04-25 13:46
Reporter:	jmaynard	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:	5.45
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Improve Hercules DASD image reporting
Description:	The detection and reporting of Hercules emulated DASD images can be improved to report more types and what type of compression is used. In addition, the reporting of DASD types 3380 and 3390 is incorrect: they're reported as 33FFFFFF80 and 33FFFFFF90. The attached patch makes these improvements.
Tags:	magic
Steps To Reproduce:
Additional Information:
Attached Files:	hercdasd.diff (2,764 bytes) 2024-04-25 13:46 https://bugs.astron.com/file_download.php?file_id=408&type=bug

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
518	[file] General	minor	always	2024-04-23 19:56	2024-04-23 19:56
Reporter:	rillig	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:	5.45
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Typo in snprintb format
Description:	In b\17no_check_sapptype, the 's' is too much.
Tags:
Steps To Reproduce:	snprintb(buf, sizeof(buf), MAGIC_SNPRINTB, 0x8000);
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
517	[file] General	minor	always	2024-04-22 20:04	2024-04-22 20:04
Reporter:	a1rind	Platform:
Assigned To:		OS:
Priority:	high	OS Version:
Status:	new	Product Version:	5.44
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	xlsx file content type is detected as application/octet-stream
Description:	Hi! An OOXML format xlsx file (attached) is being determined as an application/octet-stream. The `zipinfo` lists the following directories/files: ``` Zip file size: 9794 bytes, number of entries: 14 -rw---- 4.5 fat 1533 b- defS 24-Apr-17 13:31 [Content_Types].xml -rw---- 4.5 fat 735 b- defS 80-Jan-01 00:00 _rels/.rels -rw---- 4.5 fat 785 b- defS 80-Jan-01 00:00 docProps/app.xml -rw---- 4.5 fat 506 b- defS 24-Apr-17 13:31 docProps/core.xml -rw---- 4.5 fat 245 b- defF 23-Nov-06 15:29 docProps/custom.xml -rw---- 4.5 fat 703 b- defS 24-Apr-17 13:31 xl/_rels/workbook.xml.rels -rw---- 4.5 fat 7856 b- defS 80-Jan-01 00:00 xl/printerSettings/printerSettings1.bin -rw---- 4.5 fat 3680 b- defS 24-Apr-17 13:31 xl/styles.xml -rw---- 4.5 fat 8392 b- defS 80-Jan-01 00:00 xl/theme/theme1.xml -rw---- 4.5 fat 1826 b- defS 24-Apr-17 13:31 xl/workbook.xml -rw---- 4.5 fat 458 b- defS 24-Apr-17 13:31 xl/worksheets/_rels/sheet1.xml.rels -rw---- 4.5 fat 3765 b- defF 24-Apr-17 13:31 xl/worksheets/sheet1.xml -rw---- 4.5 fat 1408 b- defN 24-Apr-17 13:31 xl/tables/table1.xml -rw---- 4.5 fat 1415 b- defN 24-Apr-17 13:31 xl/sharedStrings.xml 14 files, 33307 bytes uncompressed, 8066 bytes compressed: 75.8% ``` If I regroup the files, the issue is fixed: ``` Zip file size: 9487 bytes, number of entries: 14 ?rw------- 2.0 unx 1533 b- defN 24-Apr-23 00:58 [Content_Types].xml ?rw------- 2.0 unx 735 b- defN 24-Apr-23 00:58 _rels/.rels ?rw------- 2.0 unx 703 b- defN 24-Apr-23 00:58 xl/_rels/workbook.xml.rels ?rw------- 2.0 unx 7856 b- defN 24-Apr-23 00:58 xl/printerSettings/printerSettings1.bin ?rw------- 2.0 unx 3680 b- defN 24-Apr-23 00:58 xl/styles.xml ?rw------- 2.0 unx 8392 b- defN 24-Apr-23 00:58 xl/theme/theme1.xml ?rw------- 2.0 unx 1826 b- defN 24-Apr-23 00:58 xl/workbook.xml ?rw------- 2.0 unx 458 b- defN 24-Apr-23 00:58 xl/worksheets/_rels/sheet1.xml.rels ?rw------- 2.0 unx 3765 b- defN 24-Apr-23 00:58 xl/worksheets/sheet1.xml ?rw------- 2.0 unx 1408 b- defN 24-Apr-23 00:58 xl/tables/table1.xml ?rw------- 2.0 unx 1415 b- defN 24-Apr-23 00:58 xl/sharedStrings.xml ?rw------- 2.0 unx 785 b- defN 24-Apr-23 00:58 docProps/app.xml ?rw------- 2.0 unx 506 b- defN 24-Apr-23 00:58 docProps/core.xml ?rw------- 2.0 unx 245 b- defN 24-Apr-23 00:58 docProps/custom.xml 14 files, 33307 bytes uncompressed, 7815 bytes compressed: 76.5% ``` This is the third issue I am creating of a similar problem. As long as the implementation depends on the order of files in an archive, we'll keep running into similar problems. What are your thoughts on this? Kind Regards! Aamir
Tags:	bug, magic
Steps To Reproduce:	file --mime-type unsupported.xlsx
Additional Information:
Attached Files:	unsupported.xlsx (9,794 bytes) 2024-04-22 20:04 https://bugs.astron.com/file_download.php?file_id=407&type=bug

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
516	[file] General	feature	always	2024-04-20 16:31	2024-04-20 16:31
Reporter:	osm0sis	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Show the found magic's offset within the file
Description:	It would be a great feature to be able to be shown the byte offset for the found magic within the checked file (hexadecimal, decimal or maybe even octal). Especially useful where the search bytes= parameter can be adjusted to the full length of a file. Thanks for your consideration!
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
507	[file] General	feature	N/A	2024-03-07 23:20	2024-04-14 00:51
Reporter:	polluks	Platform:	MacBookAir14,2
Assigned To:	christos	OS:	macOS
Priority:	normal	OS Version:	14.3.1
Status:	new	Product Version:	5.45
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Identify CSI as ESC
Description:	A patch to look an 8 bit escape like a 7 bit escape.
Tags:
Steps To Reproduce:
Additional Information:	--- file-5.45/src/ascmagic.c 2023-05-30 22:17:50.000000000 +0200 +++ ./ascmagic.c 2024-03-01 20:55:42.000000000 +0100 @@ -199,7 +199,7 @@                                 has_long_lines = ll;                 }   - if (ubuf[i] == '\033') + if ((ubuf[i] & 127) == '\033')                         has_escapes = 1;                 if (ubuf[i] == '\b')                         has_backspace = 1;
System Description
Attached Files:

Notes
(0004028) christos    2024-04-07 21:25	That matches '['? why should that print it has escapes?
(0004035) polluks    2024-04-14 00:51	It doesn't match a bracket but a Control Sequence Introducer (a short form of escape+'['). Some kind of hidden escape.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
515	[file] General	minor	always	2024-04-08 19:13	2024-04-08 19:29
Reporter:	marcoribeiro	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:	5.45
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Magic inserts linebreaks inside TIFF descriptions, making it not possible to correcly split lines
Description:	When I use the flag 'MAGIC_CONTINUE', I expect each detection to be on a separate line, but on some cases it also adds a linebreak followed by "- " inside a detection from a TIFF buffer Here is an example, using the flags MAGIC_CONTINUE | MAGIC_RAW (also happens with MAGIC_RAW is not set, but with "\n" replaced with "\012"): 'TIFF image data, little-endian, direntries=18, height=434, bps=14534, compression=none, PhotometricInterpretation=RGB, name=/home/marta/Desktop/www/file ex/files/grafa/tiff/file_example_TIFF_1MB.tiff, orientation=upper-left\n- , width=650\n- data' Note that the "width=650" should be on the previous line (or at least, it should not have the "- " before it) This (attached) TIFF image was downloaded from https://file-examples.com/index.php/sample-images-download/sample-tiff-download/ (the 1MB version)
Tags:
Steps To Reproduce:	Using the file-magic package for Python: ------------------------------------------------- import magic from pathlib import Path magic_desc = magic.open(magic.MAGIC_CONTINUE | magic.MAGIC_RAW) assert magic_desc.load() == 0 data = Path("file_example_TIFF_1MB").read_bytes() print(magic_desc.buffer(data)) ------------------------------------------------- Using the python-magic package: ------------------------------------------------- import magic from pathlib import Path magic_desc = magic.Magic(keep_going=True, raw=True) data = Path("file_example_TIFF_1MB").read_bytes() print(magic_desc.from_buffer(data)) ------------------------------------------------- Both cases should output: TIFF image data, little-endian, direntries=18, height=434, bps=14534, compression=none, PhotometricInterpretation=RGB, name=/home/marta/Desktop/www/file ex/files/grafa/tiff/file_example_TIFF_1MB.tiff, orientation=upper-left - , width=650 - data
Additional Information:
Attached Files:	file_example_TIFF_1MB.tiff (1,131,930 bytes) 2024-04-08 19:13 https://bugs.astron.com/file_download.php?file_id=406&type=bug

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
514	[file] General	minor	always	2024-04-07 09:13	2024-04-08 17:58
Reporter:	slatian	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.45
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	HEAD
		Target Version:
Summary:	xhtml File gets detected as just xml OR html
Description:	Letting file detect an xhtml file be detected results in it either being detected as an xml file or a regular html file. While not strictly wron the result in iaccurate. The expected media type would be: application/xhtml+xml For example files see the xhtml specification: https://www.w3.org/TR/xhtml1/#strict This issue was originally filed on the xdg-utils bugtracker: https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/248
Tags:
Steps To Reproduce:	Take the first example document from the specification ("Virtual Library"), save it to a file. Run file on it and it gets detected as application/xml. Take the second (MathML) example document, save and run file on it. It gets detected as plain text/html.
Additional Information:
Attached Files:

Notes
(0004034) christos    2024-04-08 17:58	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
511	[file] General	minor	always	2024-03-19 23:04	2024-04-08 17:00
Reporter:	slatian	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.45
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	HEAD
		Target Version:
Summary:	html file gets misdetected as csv
Description:	An html file generated by `cargo doc` gets misidentified as csv. The original bug is: https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/246 An example of a categorized file has been uploaded to: https://pastebin.com/raw/S55SiBGc
Tags:
Steps To Reproduce:	run the `file` command on the linked file.
Additional Information:
Attached Files:

Notes
(0004033) christos    2024-04-08 17:00	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
505	[file] General	minor	have not tried	2024-02-23 10:40	2024-04-08 16:06
Reporter:	monperrus	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	feedback	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	support of multi-part zip archives
Description:	zipsplit creates multi-part zip archives, file can only recognize some files from it.
Tags:
Steps To Reproduce:	to create the split file: zip -s 3 foo.zip bigfile.dat Then: file foo.z* Actual behavior: foo.z01: Zip multi-volume archive data, at least PKZIP v2.50 to extract foo.z02: data foo.z03: data foo.zip: data Expected behavior: foo.z01: Zip multi-volume archive data, at least PKZIP v2.50 to extract foo.z02: Zip multi-volume archive data, at least PKZIP v2.50 to extract foo.z03: Zip multi-volume archive data, at least PKZIP v2.50 to extract foo.zip: Zip multi-volume archive data, at least PKZIP v2.50 to extract
Additional Information:
Attached Files:

Notes
(0004017) jsummers    2024-03-01 13:54	As far as I know, it's essentially impossible to identify ZIP fragments that are neither first nor last. I couldn't reproduce your results for the last fragment. (And it might be possible to identify it as the last fragment, instead of just as generic Zip data.) $ zip -s 3 foo.zip bigfile.dat $ file foo.z* foo.z01: Zip multi-volume archive data, at least PKZIP v2.50 to extract foo.z02: data foo.z03: data foo.zip: Zip archive data, made by v3.0 UNIX, extract using at least v2.0, last modified, last modified Sun, Mar 01 2024 08:43:12, uncompressed size 10518450, method=deflate $ file --version file-5.45
(0004022) monperrus    2024-03-04 18:39	I confirm I can also identify the last fragment. > As far as I know, it's essentially impossible to identify ZIP fragments that are neither first nor last. argh, too bad. thanks a lot, we can close then.
(0004032) christos    2024-04-08 16:06	I am not sure if it is possible, since the file parts have no identifying magic...

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
512	[file] General	minor	always	2024-03-20 13:55	2024-04-08 16:05
Reporter:	vinc17	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	feedback	Product Version:	5.45
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	PostScript page list (.dsc) misidentified as PostScript document
Description:	The pdf2dsc script from Ghostscript can generate a .dsc file consisting of a PostScript page list. This file looks like a real PostScript document, but it cannot normally be read with a PostScript viewer (actually, it is not the intent). Thus "file" should not identify it as a PostScript document like what it currently does.
Tags:
Steps To Reproduce:	$ cat test.dsc %!PS-Adobe-3.0 %%DocumentMedia: y841.89x595.276 595.276 841.89 70 white () %%Pages: 1 %%EndComments %%BeginProlog /Page null def /Page# 0 def /PDFSave null def /DSCPageCount 0 def /DoPDFPage {dup /Page# exch store dup dopdfpages } def %%EndProlog %%BeginSetup (test.pdf) (r) file { DELAYSAFER { .setsafe } if } stopped pop  runpdfbegin  process_trailer_attrs %%EndSetup %%Page: 1 1 %%PageMedia: y841.89x595.276 1 DoPDFPage %%Trailer runpdfend %%EOF $ file test.dsc test.dsc: PostScript document text conforming DSC level 3.0 It should have output something like "PostScript DSC file". I'm not sure about "file -i"; I'd say that text/plain is more appropriate than application/postscript since such files will typically be viewed with a text viewer.
Additional Information:	I'm not sure how such a file can be identified. Perhaps looking for "/DSCPageCount 0 def" (which is guaranteed to be there, as this can be seen in lib/pdf2dsc.ps from Ghostscript).
Attached Files:

Notes
(0004023) vinc17    2024-03-20 14:20	Additional information: The file seemed to have been "readable" by some PostScript viewers in the past, as one can see at https://bugs.ghostscript.com/show_bug.cgi?id=697529 but as said by the Ghostscript developer, the .dsc file "uses Ghostscript-specific PostScript extensions" and a user should not generate such a file if the goal is to get a PostScript file readable by a PostScript viewer. So, what's important is that such a file should be regarded as some form of plain text file.
(0004031) christos    2024-04-08 16:05	DSC is https://en.wikipedia.org/wiki/Document_Structuring_Conventions. I am not sure how to identify the specific ghostscript extensions. Can the ghostscript developer give some hints on how to identify them?

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
510	[file] General	minor	always	2024-03-18 12:46	2024-04-08 15:58
Reporter:	a1rind	Platform:
Assigned To:	christos	OS:
Priority:	high	OS Version:
Status:	resolved	Product Version:	5.44
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	HEAD
		Target Version:
Summary:	docx file is determined as zip
Description:	Hi! An OOXML format docx file (attached) is being determined as an application/zip. The `zipinfo` lists the following directories/files: ``` Zip file size: 46058 bytes, number of entries: 36 -rw---- 0.0 fat 3016 b- stor 80-Jan-01 00:00 [Content_Types].xml -rw---- 0.0 fat 646372 t- defN 80-Jan-01 00:00 word/styles.xml -rw---- 0.0 fat 64407 t- defN 80-Jan-01 00:00 word/numbering.xml -rw---- 0.0 fat 1222 t- defN 80-Jan-01 00:00 word/fontTable.xml -rw---- 0.0 fat 8901 t- defN 80-Jan-01 00:00 word/header1.xml -rw---- 0.0 fat 4411 t- defN 80-Jan-01 00:00 word/header2.xml -rw---- 0.0 fat 4411 t- defN 80-Jan-01 00:00 word/header3.xml -rw---- 0.0 fat 2420 t- defN 80-Jan-01 00:00 word/footer1.xml -rw---- 0.0 fat 1743 t- defN 80-Jan-01 00:00 word/footnotes.xml -rw---- 0.0 fat 1737 t- defN 80-Jan-01 00:00 word/endnotes.xml -rw---- 0.0 fat 2377 t- defN 80-Jan-01 00:00 word/settings.xml -rw---- 0.0 fat 183 t- defN 80-Jan-01 00:00 word/webSettings.xml -rw---- 0.0 fat 58909 t- defN 80-Jan-01 00:00 word/document.xml -rw---- 0.0 fat 739 t- defN 80-Jan-01 00:00 _rels/.rels -rw---- 0.0 fat 218 t- defN 80-Jan-01 00:00 customXml/itemProps1.xml -rw---- 0.0 fat 11932 t- defN 80-Jan-01 00:00 customXml/item1.xml -rw---- 0.0 fat 218 t- defN 80-Jan-01 00:00 customXml/itemProps2.xml -rw---- 0.0 fat 587 t- defN 80-Jan-01 00:00 customXml/item2.xml -rw---- 0.0 fat 218 t- defN 80-Jan-01 00:00 customXml/itemProps3.xml -rw---- 0.0 fat 219 t- defN 80-Jan-01 00:00 customXml/item3.xml -rw---- 0.0 fat 501 t- defN 80-Jan-01 00:00 docProps/app.xml -rw---- 0.0 fat 712 t- defN 80-Jan-01 00:00 docProps/core.xml -rw---- 0.0 fat 591 t- defN 80-Jan-01 00:00 docProps/custom.xml -rw---- 0.0 fat 155 t- defN 80-Jan-01 00:00 word/_rels/comments.xml.rels -rw---- 0.0 fat 155 t- defN 80-Jan-01 00:00 word/_rels/header1.xml.rels -rw---- 0.0 fat 287 t- defN 80-Jan-01 00:00 word/_rels/header2.xml.rels -rw---- 0.0 fat 287 t- defN 80-Jan-01 00:00 word/_rels/header3.xml.rels -rw---- 0.0 fat 155 t- defN 80-Jan-01 00:00 word/_rels/footer1.xml.rels -rw---- 0.0 fat 155 t- defN 80-Jan-01 00:00 word/_rels/footnotes.xml.rels -rw---- 0.0 fat 155 t- defN 80-Jan-01 00:00 word/_rels/endnotes.xml.rels -rw---- 0.0 fat 2662 t- defN 80-Jan-01 00:00 word/_rels/document.xml.rels -rw---- 0.0 fat 680 b- defN 80-Jan-01 00:00 word/media/image1.wmf -rw---- 0.0 fat 4569 t- defN 80-Jan-01 00:00 word/theme/theme1.xml -rw---- 0.0 fat 295 t- defN 80-Jan-01 00:00 customXml/_rels/item1.xml.rels -rw---- 0.0 fat 295 t- defN 80-Jan-01 00:00 customXml/_rels/item2.xml.rels -rw---- 0.0 fat 295 t- defN 80-Jan-01 00:00 customXml/_rels/item3.xml.rels 36 files, 826189 bytes uncompressed, 41764 bytes compressed: 94.9% ``` It was tested on Debian Bookworm using file version 5.44. Also, when using the latest msooxml file (https://github.com/file/file/blob/master/magic/Magdir/msooxml,), the content type is not correctly determined. Can you suggest rules that should be updated in msooxml to fix this? Any help in this regard is highly appreciated. Kind Regards! Aamir
Tags:	bug, magic
Steps To Reproduce:	file --mime-type unsupported.docx
Additional Information:
Attached Files:	unsupported.docx (46,058 bytes) 2024-03-18 12:46 https://bugs.astron.com/file_download.php?file_id=405&type=bug

Notes
(0004024) a1rind    2024-03-21 16:27	Do the rules defined in msooxml depend on the order of the files in an OOXML document?
(0004030) christos    2024-04-08 15:58	Fixed, thanks

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
508	[file] General	major	always	2024-03-08 14:39	2024-04-07 21:27
Reporter:	jor	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.44
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	HEAD
		Target Version:
Summary:	JPEG header detection: name use count (50) exceeded
Description:	This is related to issue 0000152: JPEG header detection: name use count (30) exceeded It seems the new limit (50) is not enough. I just got the same error on a regular panoramic photo taken on an iPhone 6S. The file has not been modified in any way, it comes straight from the phone. It seems it has 60 different "EXIF fields": Manufacturer Model Orientation X-Resolution Y-Resolution Resolution Unit Software Date and Time YCbCr Positioning Compression X-Resolution Y-Resolution Resolution Unit Exposure Time F-Number ISO Speed Ratings Exif Version Date and Time (Original) Date and Time (Digitized) Offset Time For DateTime Offset Time For DateTimeOriginal Offset Time For DateTimeDigitized Components Configuration Shutter Speed Aperture Brightness Exposure Bias Metering Mode Flash Focal Length Sub-second Time (Original) Sub-second Time (Digitized) FlashPixVersion Color Space Pixel X Dimension Pixel Y Dimension Sensing Method Scene Type Custom Rendered White Balance Focal Length in 35mm Film Scene Capture Type Lens Specification Lens Make Lens Model North or South Latitude Latitude East or West Longitude Longitude Altitude Reference Altitude Speed Unit Speed of GPS Receiver GPS Image Direction Reference GPS Image Direction Reference for Bearing of Destination Bearing of Destination GPS Date GPS Horizontal Positioning Error ThumbnailSize I am happy to send the image in question to anyone that needs it. Can the limit be bumped further?
Tags:
Steps To Reproduce:	file IMG_0267.JPG
Additional Information:
Attached Files:

Notes
(0004029) christos    2024-04-07 21:27	bumped to 100

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
513	[file] General	text	always	2024-03-21 11:45	2024-04-07 19:25
Reporter:	Emanuele Aina	Platform:
Assigned To:	christos	OS:
Priority:	low	OS Version:
Status:	resolved	Product Version:	5.45
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	HEAD
		Target Version:
Summary:	mygetopt.h licensing terms are outdated (NetBSD moved from BSD-4-Clause to BSD-2-Clause)
Description:	https://github.com/file/file/blob/70819a8a96d69c7ce1b106b8cfe7f965e3c79115/src/mygetopt.h currently reports the BDS-4-Clause licensing terms, including the problematic advertising clause. However the NetBSD foundation relicensed everything to the BSD-2-Clause in 2008, see https://www.netbsd.org/about/redistribution.html#why2clause (the file has a CVS id from 2007). They also state that "Third parties are encouraged to change the license on any files which have a 4-clause license contributed to the NetBSD Foundation to a 2-clause license." so it would be nice to update the licensing terms of the affected file, to make the life of licensing auditors slightly easier. :D
Tags:	documentation
Steps To Reproduce:	Just check src/mygetopt.h
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
509	[file] General	feature	N/A	2024-03-08 21:33	2024-04-07 17:56
Reporter:	polluks	Platform:	MacBookAir14,2
Assigned To:	christos	OS:	macOS
Priority:	normal	OS Version:	14.3.1
Status:	resolved	Product Version:	5.45
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	HEAD
		Target Version:
Summary:	geos update
Description:	some magic for cvt files
Tags:	magic
Steps To Reproduce:
Additional Information:
System Description
Attached Files:	geos (816 bytes) 2024-03-08 21:33 https://bugs.astron.com/file_download.php?file_id=404&type=bug

Notes
(0004027) christos    2024-04-07 17:56	Added

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
276	[file] General	minor	always	2021-07-26 15:24	2024-04-06 13:55
Reporter:	abathur	Platform:	intel/x86_64
Assigned To:	christos	OS:	macOS
Priority:	normal	OS Version:	10.15
Status:	resolved	Product Version:	5.40
Product Build:		Resolution:	reopened
Projection:	none
ETA:	none	Fixed in Version:	HEAD
		Target Version:
Summary:	between 5.37 and 5.39, file starts identifying bin/sh script with patched shebang as awk/perl
Description:	I noticed a patched copy of esh 0.1.1 getting identified as an "awk or perl script" by newer versions of file (confirmed I see this in file 5.39 from nixpkgs and file 5.40 from homebrew). I've attached an unpatched copy named `esh` and a patched copy named `nix_esh`, but I assume the salient part is the fact that it has had its shebang patched from /bin/sh to /nix/store/pcjan45rssdn01cxx3sjg70avjg6c3ni-bash-4.4-p23/bin/sh Output here is captured on macOS, but I've confirmed the same behavior with file 5.39 in Linux (NixOS).
Tags:
Steps To Reproduce:	# system/macOS file $ file --version file-5.37 magic file from /usr/share/file/magic # unpatched /bin/sh shebang $ file esh esh: POSIX shell script text executable, ASCII text # shebang patched by Nix to /nix/store/pcjan45rssdn01cxx3sjg70avjg6c3ni-bash-4.4-p23/bin/sh $ file nix_esh nix_esh: a /nix/store/pcjan45rssdn01cxx3sjg70avjg6c3ni-bash-4.4-p23/bin/sh script text executable, ASCII text # file from nixpkgs $ file --version file-5.39 magic file from /nix/store/77p3lid93i5xjgdi9vkj3zqcpf2zddlw-file-5.39/share/misc/magic # unpatched /bin/sh shebang $ file esh esh: POSIX shell script, ASCII text executable # shebang patched by Nix to /nix/store/pcjan45rssdn01cxx3sjg70avjg6c3ni-bash-4.4-p23/bin/sh $ file nix_esh nix_esh: awk or perl script, ASCII text # file from homebrew $ file --version file-5.40 magic file from /usr/local/Cellar/libmagic/5.40/share/misc/magic # unpatched /bin/sh shebang $ file esh esh: POSIX shell script, ASCII text executable # shebang patched by Nix to /nix/store/pcjan45rssdn01cxx3sjg70avjg6c3ni-bash-4.4-p23/bin/sh $ file nix_esh nix_esh: awk or perl script, ASCII text
Additional Information:
Attached Files:	esh (4,302 bytes) 2021-07-26 15:24 https://bugs.astron.com/file_download.php?file_id=231&type=bug nix_esh (4,710 bytes) 2021-07-26 15:24 https://bugs.astron.com/file_download.php?file_id=232&type=bug

Notes
(0003630) christos    2021-07-30 08:44	With the HEAD of the file code this reports: $ ./file -m ../magic/magic.mgc ~/nix_esh /Users/christos/nix_esh: a /nix/store/pcjan45rssdn01cxx3sjg70avjg6c3ni-bash-4.4-p23/bin/sh script, ASCII text executable
(0003633) abathur    2021-07-31 22:28	Thanks--I'll keep an eye out for the next release. (I do see the same after figuring out how to rebuild the Nix package from the latest commit on the GH mirror).
(0003654) christos    2021-10-28 15:33	Release has been out.
(0004025) abathur    2024-04-04 14:22	This morning I noticed that this regressed at some point between 5.43 and 5.44: $ file --version file-5.44 ... $ file /nix/store/y2jm9585rj81y9ks04b7ky2631ahgv3s-esh-0.1.1/bin/esh /nix/store/y2jm9585rj81y9ks04b7ky2631ahgv3s-esh-0.1.1/bin/esh: awk or perl script, ASCII text $ file --version file-5.43 ... $ file /nix/store/y2jm9585rj81y9ks04b7ky2631ahgv3s-esh-0.1.1/bin/esh /nix/store/y2jm9585rj81y9ks04b7ky2631ahgv3s-esh-0.1.1/bin/esh: a /nix/store/7xmqfgfgipjypqprhz0xw6bd3jb58z3y-bash-5.2p26/bin/sh script, ASCII text executable
(0004026) christos    2024-04-06 13:55	Fixed again, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
217	[file] General	tweak	always	2020-12-21 12:02	2024-03-04 17:19
Reporter:	Helge Kreutzmann	Platform:
Assigned To:	christos	OS:
Priority:	low	OS Version:
Status:	assigned	Product Version:	5.39
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Issues in file man pages
Description:	Dear file maintainer, the manpage-l10n project maintains a large number of translations of man pages both from a large variety of sources (including file) as well for a large variety of target languages. During their work translators notice different possible issues in the original (english) man pages. Sometimes this is a straightforward typo, sometimes a hard to read sentence, sometimes this is a convention not held up and sometimes we simply do not understand the original. We use several distributions as sources and update regularly (at least every 2 month). This means we are fairly recent (some distributions like archlinux also update frequently) but might miss the latest upstream version once in a while, so the error might be already fixed. We apologize and ask you to close the issue immediately if this should be the case, but given the huge volume of projects and the very limited number of volunteers we are not able to double check each and every issue. Secondly we translators see the manpages in the neutral po format, i.e. converted and harmonized, but not the original source (be it man, groff, xml or other). So we cannot provide a true patch (where possible), but only an approximation which you need to convert into your source format. Finally the issues I'm reporting have accumulated over time and are not always discovered by me, so sometimes my description of the problem my be a bit limited - do not hesitate to ask so we can clarify them. I'm now reporting the errors for your project. If future reports should use another channel, please let me know. Man page: file.1 Issue: What ist "E<.Bk -words>"? "E<.Nm> E<.Bk -words> E<.Op Fl bcdEhiklLNnprsSvzZ0> E<.Op Fl Fl apple> E<.Op " "Fl Fl exclude-quiet> E<.Op Fl Fl extension> E<.Op Fl Fl mime-encoding> E<.Op " "Fl Fl mime-type> E<.Op Fl e Ar testname> E<.Op Fl F Ar separator> E<.Op Fl f " "Ar namefile> E<.Op Fl m Ar magicfiles> E<.Op Fl P Ar name=value> E<.Ar> E<." "Ek> E<.Nm> E<.Fl C> E<.Op Fl m Ar magicfiles> E<.Nm> E<.Op Fl Fl help>" -- Man page: file.1 Issue: Two quote signs around magic / magic numbers does not make sense "in the standard include directory. These files have a E<.Dq \"magic number" "\"> stored in a particular place near the beginning of the file that tells " "the E<.Tn UNIX> operating system that the file is a binary executable, and " "which of several types thereof. The concept of a E<.Dq \"magic\"> has been " "applied by extension to data files. Any file with some invariant identifier " "at a small fixed offset into the file can usually be described in this way. " "The information identifying these files is read from the compiled magic file " "E<.Pa /usr/share/file/misc/magic.mgc>, or the files in the directory E<.Pa /" "usr/share/file/misc/magic> if the compiled file does not exist. In " "addition, if E<.Pa $HOME/.magic.mgc> or E<.Pa $HOME/.magic> exists, it will " "be used in preference to the system magic files." -- Man page: file.1 Issue: the file command â the command <.Nm> "Causes the file command to output the file type and creator code as used by " "older MacOS versions. The code consists of eight letters, the first " "describing the file type, the latter the creator. This option works " "properly only for file formats that have the apple-style output defined." -- Man page: file.1 Issue: option â (This) option "option causes symlinks not to be followed (on systems that support symbolic " "links). This is the default if the environment variable E<.Dv " "POSIXLY_CORRECT> is not defined." "option causes symlinks to be followed, as the like-named option in E<.Xr ls " "1> (on systems that support symbolic links). This is the default if the " "environment variable E<.Ev POSIXLY_CORRECT> is defined." -- Man page: file.1 Issue: file â E<.Nm> "Causes the file command to output mime type strings rather than the more " "traditional human readable ones. Thus it may say E<.Sq text/plain; " "charset=us-ascii> rather than E<.Dq ASCII text>." "On systems where libseccomp E<.Pa ( https://github.com/seccomp/libseccomp>) " "is available, the E<.Fl S> flag disables sandboxing which is enabled by " "default. This option is needed for file to execute external decompressing " "programs, i.e. when the E<.Fl z> flag is specified and the built-in " "decompressors are not available. On systems where sandboxing is not " "available, this option has no effect." "The magic file entries have been collected from various sources, mainly " "USENET, and contributed by various authors. Christos Zoulas (address below) " "will collect additional or corrected magic file entries. A consolidation of " "magic file entries will be distributed periodically." "John Gilmore revised the code extensively, making it better than the first " "version. Geoff Collyer found several inadequacies and provided some magic " "file entries. Contributions of the E<.Sq \\*[Am]> operator by Rob McMahon, " "E<.Aq cudcv@warwick.ac.uk>, 1989." "E<.Em Note:> This Debian version of file was built without seccomp support, " "so this option has no effect." -- Man page: file.1 Issue: option â flag? "On systems where libseccomp E<.Pa ( https://github.com/seccomp/libseccomp>) " "is available, E<.Nm> is enforces limiting system calls to only the ones " "necessary for the operation of the program. This enforcement does not " "provide any security benefit when E<.Nm> is asked to decompress input files " "running external programs with the E<.Fl z> option. To enable execution of " "external decompressors, one needs to disable sandboxing using the E<.Fl S> " "flag." -- Man page: file.1 Issue: Missing full stop. "Some of the encoding logic is hard-coded in encoding.c and can be moved to " "the magic files if we had a !:charset annotation" -- Man page: file.1 Issue: This bug was closed in 2008? "Store arbitrarily long strings, for example for %s patterns, so that they " "can be printed out. Fixes Debian bug #271672. This can be done by " "allocating strings in a string pool, storing the string pool at the end of " "the magic file and converting all the string pointers to relative offsets " "from the string pool." -- Man page: file.1 Issue 1: security considerations) â security) considerations Issue 2: so move around the file â to move around in the file "If the offsets specified internally in the file exceed the buffer size ( E<." "Dv HOWMANY> variable in file.h), then we don't seek to that offset, but we " "give up. It would be better if buffer managements was done when the file " "descriptor is available so move around the file. One must be careful though " "because this has performance (and thus security considerations)." -- Man page: file.1 Issue: is E<.Ek> â file? This long string is difficult to review for translation "E<.Nm> E<.Bk -words> E<.Op Fl bcdEhiklLNnprsSvzZ0> E<.Op Fl Fl apple> E<.Op " "Fl Fl extension> E<.Op Fl Fl mime-encoding> E<.Op Fl Fl mime-type> E<.Op Fl " "e Ar testname> E<.Op Fl F Ar separator> E<.Op Fl f Ar namefile> E<.Op Fl m " "Ar magicfiles> E<.Op Fl P Ar name=value> E<.Ar> E<.Ek> E<.Nm> E<.Fl C> E<.Op " "Fl m Ar magicfiles> E<.Nm> E<.Op Fl Fl help>" -- Man page: file.1 Issue: Two quote signs around magic / magic numbers does not make sense "in the standard include directory. These files have a E<.Dq \"magic number" "\"> stored in a particular place near the beginning of the file that tells " "the E<.Tn UNIX> operating system that the file is a binary executable, and " "which of several types thereof. The concept of a E<.Dq \"magic\"> has been " "applied by extension to data files. Any file with some invariant identifier " "at a small fixed offset into the file can usually be described in this way. " "The information identifying these files is read from /etc/magic and the " "compiled magic file E<.Pa /usr/share/misc/magic.mgc>, or the files in the " "directory E<.Pa /usr/share/misc/magic> if the compiled file does not exist. " "In addition, if E<.Pa $HOME/.magic.mgc> or E<.Pa $HOME/.magic> exists, it " "will be used in preference to the system magic files."
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003517) christos    2021-01-03 20:45	Issue: What ist "E<.Bk -words>"? - See the "Keep" macro https://www.freebsd.org/cgi/man.cgi?query=mdoc&sektion=7 Issue: Two quote signs around magic / magic numbers does not make sense - Removed, don't make a difference Issue: the file command â the command <.Nm> - Use .Nm Issue: option â (This) option - Added "This" Issue: file â E<.Nm> - fixed .Nm Issue: option â flag? - changed all to option Issue: Missing full stop. - fixed. Issue: This bug was closed in 2008? - No it is still broken (string limits in magic descriptions) Issue 1: security considerations) â security) considerations Issue 2: so move around the file â to move around in the file - Rewrote and clarified. Issue: is E<.Ek> â file? This long string is difficult to review for translation - This is the list of flags. .Ek is the closing of .Bk macro. Issue: Two quote signs around magic / magic numbers does not make sense - duplicate, fixed.
(0003524) Helge Kreutzmann    2021-01-05 15:39	Thanks for the swift handling, no more comments from my side.
(0003707) Helge Kreutzmann    2022-03-09 17:14	Has this already landed in some kind of release? I wonder because I still see some issues in file(1) in all our upstream distributions.
(0003910) Helge Kreutzmann    2023-03-11 13:36	As of mid February 2023 I still see them in the major distros. What is the ETA for including them?
(0004018) Helge Kreutzmann    2024-03-03 11:14	Hello Christos, this is my yearly ping. Do you have an ETA for landing them in a release? Thanks!
(0004019) Helge Kreutzmann    2024-03-03 11:17	I apologize for my last note, all but one change (occuring twice) are actually fixed. So the only one left is: file → E<.Nm> "The magic file entries have been collected from various sources, mainly " "USENET, and contributed by various authors. Christos Zoulas (address below) " "will collect additional or corrected magic file entries. A consolidation of " "magic file entries will be distributed periodically." "John Gilmore revised the code extensively, making it better than the first " "version. Geoff Collyer found several inadequacies and provided some magic " "file entries. Contributions of the E<.Sq \\*[Am]> operator by Rob McMahon, " "E<.Aq cudcv@warwick.ac.uk>, 1989."
(0004020) christos    2024-03-04 00:10	These refer to the "magic file" not to the file command (the file containing magic entries). I am not sure when the next release will be. Need to find some spare time :-)
(0004021) Helge Kreutzmann    2024-03-04 17:19	Thanks, I marked this appropriately in our sources, so then all issues reported by me are fix and this bug can be closed.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
504	[file] General	feature	always	2024-02-20 09:09	2024-03-01 03:33
Reporter:	skissane	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.45
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	HEAD
		Target Version:
Summary:	Recognise z/OS Program Objects
Description:	Currently, magic/Magdir/ibm370 recognises various old IBM mainframe executable format, but does not recognise the current z/OS executable format defined by IBM ("z/OS Program Object"), which is the IBM mainframe executable format you are most likely to encounter in the wild today. I am supplying a patch to recognise this format. (It is quite simple, it is just "IEWPLMH " as magic at start of the file, except that is in EBCDIC instead of ASCII.)
Tags:	magic
Steps To Reproduce:	1. Download https://github.com/ZOSOpenTools/bashport/releases/download/STABLE_bashport_2038/bash-5.2.21.20240126_140514.zos.pax.Z (port of bash to IBM z/OS) 2. Extract the file bin/bash from that archive (it is a compressed tar archive, so tar xzf can extract it) 3. file ./bash EXPECTED: something like "z/OS Program Object executable" ACTUAL: reports "data" 4. Apply attached patch to magic/Magdir/ibm370 5. file -m ibm370.new ./bash ACTUAL: reports "z/OS Program Object executable"
Additional Information:	I attach a patch to magic/Magdir/ibm370. I also attach (gzipped) the bash executable I mention above so you don't have to download and extract it. Also, there was a comment line saying "What the heck *is* "USS/370"?" The answer is, "USS/370" is a very old (early 1990s) name for the IBM's Unix compatibility subsystem for z/OS (formerly known as MVS or OS/390). So I replaced that question with its answer. I haven't changed the name in the magic rules, since for those very old executable formats (which IBM doesn't use any more) it is arguably the correct name.
Attached Files:	bash.zos.gz (1,481,466 bytes) 2024-02-20 09:09 https://bugs.astron.com/file_download.php?file_id=403&type=bug ibm370.patch (937 bytes) 2024-02-20 09:09 https://bugs.astron.com/file_download.php?file_id=402&type=bug

Notes
(0004016) christos    2024-03-01 03:33	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
506	[file] General	feature	always	2024-02-26 12:54	2024-03-01 03:31
Reporter:	Martin	Platform:	Linux
Assigned To:	christos	OS:	Arch Linux
Priority:	normal	OS Version:	N/A
Status:	resolved	Product Version:	5.45
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	HEAD
		Target Version:
Summary:	Detect PNGs with APNG extension as such
Description:	file currently does not have any magic values for APNG PNG's, resulting it to label everything as PNG. Example image is provided on wikipedia. https://en.wikipedia.org/wiki/APNG APNG has been supported by all major browsers for years and as of recently is being standardized in the new PNG spec as a core feature. See initial changelog fragment in https://www.w3.org/TR/png-3/#changes-20031110 and scroll *UP* to see the subsequent ones. And the Explainer document for the Third Edition PNG spec https://github.com/w3c/PNG-spec/blob/main/Third_Edition_Explainer.md
Tags:
Steps To Reproduce:	imagemagick's identify seems to have the same issue as file (unsure which magic file it uses, perhaps the one from file), but at least it can be forced as APNG to show the frame count if any. Using the wikipedia page image: [0] % file ball.png ball.png: PNG image data, 100 x 100, 8-bit/color RGBA, non-interlaced [0] % identify ball.png ball.png PNG 100x100 100x100+0+0 8-bit sRGB 61968B 0.000u 0:00.000 [0] % identify apng:ball.png apng:ball.png=>ball.png[0] APNG 100x100 100x100+0+0 8-bit sRGB 53670B 0.000u 0:00.000 apng:ball.png=>ball.png[1] APNG 39x63 100x100+30+36 8-bit sRGB 0.000u 0:00.000 apng:ball.png=>ball.png[2] APNG 39x56 100x100+30+40 8-bit sRGB 0.000u 0:00.000 apng:ball.png=>ball.png[3] APNG 39x65 100x100+30+34 8-bit sRGB 0.000u 0:00.000 apng:ball.png=>ball.png[4] APNG 39x77 100x100+30+22 8-bit sRGB 0.000u 0:00.000 apng:ball.png=>ball.png[5] APNG 39x81 100x100+30+18 8-bit sRGB 0.000u 0:00.000 apng:ball.png=>ball.png[6] APNG 39x83 100x100+30+16 8-bit sRGB 0.000u 0:00.000 apng:ball.png=>ball.png[7] APNG 39x85 100x100+30+14 8-bit sRGB 0.000u 0:00.000 apng:ball.png=>ball.png[8] APNG 39x91 100x100+30+8 8-bit sRGB 0.000u 0:00.000 apng:ball.png=>ball.png[9] APNG 39x97 100x100+30+2 8-bit sRGB 0.000u 0:00.000 apng:ball.png=>ball.png[10] APNG 39x37 100x100+30+2 8-bit sRGB 0.000u 0:00.000 apng:ball.png=>ball.png[11] APNG 39x36 100x100+30+2 8-bit sRGB 0.000u 0:00.000 apng:ball.png=>ball.png[12] APNG 39x37 100x100+30+2 8-bit sRGB 0.000u 0:00.000 apng:ball.png=>ball.png[13] APNG 39x97 100x100+30+2 8-bit sRGB 0.000u 0:00.000 apng:ball.png=>ball.png[14] APNG 39x95 100x100+30+4 8-bit sRGB 0.000u 0:00.000 apng:ball.png=>ball.png[15] APNG 39x91 100x100+30+8 8-bit sRGB 0.000u 0:00.000 apng:ball.png=>ball.png[16] APNG 39x89 100x100+30+10 8-bit sRGB 0.000u 0:00.000 apng:ball.png=>ball.png[17] APNG 39x85 100x100+30+14 8-bit sRGB 0.000u 0:00.000 apng:ball.png=>ball.png[18] APNG 39x79 100x100+30+20 8-bit sRGB 0.000u 0:00.000 apng:ball.png=>ball.png[19] APNG 39x75 100x100+30+24 8-bit sRGB 0.000u 0:00.000
Additional Information:
Attached Files:

Notes
(0004015) christos    2024-03-01 03:31	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
503	[file] General	major	N/A	2024-02-12 23:18	2024-03-01 02:56
Reporter:	marcoxa	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.45
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	HEAD
		Target Version:
Summary:	Man pages imprecisions
Description:	Hi I have been poring over the manual pages to try to understand some of the fine points of the magic file format. I am referring especially to the magic(5) man page. And I would like to ask for clarifications. Here are my observations. When describing "indirect" offsets the explanation contains, IMHO, the following imprecision. (1) The syntax for indirect addresses is given as  (( x [[.,][bBcCeEfFgGhHiIlmsSqQ]][+-][ y ]) However, in the examples further below in the man page, there is no double opening parenthesis. (2) the 'l' "type" is not mentioned in the manual (should it be "long"? Is 'L', for "long" "big endian" missing?). (3) Given the examples in the man page, it appears that the syntax for indirect addresses is really  ( x [[.,][bBcCeEfFgGhHiIlmsSqQ]][-+*/%&|^][ y ]) with 'y' that can actually be a (unsigned) number or '('[-+]n')' with 'n' an unsigned number; or maybe with more operators beyond minus and plus? Is this a correct interpretation? If so, the manual should be updated, possibly writing down a full grammar for the indirect addresses. Does this make sense? Thanks for the consideration. Geia sou Marco
Tags:	documentation
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0004014) christos    2024-03-01 02:56	1. The [[ has been changed to [ 2. The Ll types have been added 3. The operators are described later: If this indirect offset cannot be used directly, simple calculations are possible: appending .Em [+-*/%\*[Am]|^]number inside parentheses allows one to modify the value read from the file before it is used as an offset: Thank you!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
485	[file] General	minor	always	2023-11-04 12:31	2024-02-29 03:51
Reporter:	r4gn4r0x	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.44
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	HEAD
		Target Version:
Summary:	MSDOS executables incorrectly classified as "Windows Icons Library 16-bit"
Description:	An MSDOS executable, previously classified with file 5.38 as "MS-DOS executable" now gets classified as "Windows Icons Library 16-bit" with file 5.44.
Tags:	magic
Steps To Reproduce:	$ file --version file-5.38 magic file from /etc/magic:/usr/share/misc/magic $ file ~/.wine32/drive_c/windows/rundll.exe /home/user/.wine32/drive_c/windows/rundll.exe: MS-DOS executable $ file --version file-5.44 magic file from /etc/magic:/usr/share/misc/magic $ file ~/.wine32/drive_c/windows/rundll.exe /home/user/.wine32/drive_c/windows/rundll.exe: Windows Icons Library 16-bit
Additional Information:	Tested on the exact same EXE from a Wine installation on Ubuntu 22.04.
Attached Files:

Notes
(0003978) r4gn4r0x    2023-11-04 14:13	Other examples : $ file --version file-5.44 magic file from /etc/magic:/usr/share/misc/magic $ file ~/.wine32/drive_c/windows/rundll.exe ~/.wine32/drive_c/windows/system32/gdi.exe ~/.wine32/drive_c/windows/system32/user.exe ~/.wine32/drive_c/windows/system32/mouse.drv ~/.wine32/drive_c/windows/system32/winaspi.dll /home/user/.wine32/drive_c/windows/rundll.exe: Windows Icons Library 16-bit /home/user/.wine32/drive_c/windows/system32/gdi.exe: Windows Icons Library 16-bit /home/user/.wine32/drive_c/windows/system32/user.exe: Windows Icons Library 16-bit /home/user/.wine32/drive_c/windows/system32/mouse.drv: Windows Icons Library 16-bit /home/user/.wine32/drive_c/windows/system32/winaspi.dll: Windows Icons Library 16-bit $ file --version file-5.38 magic file from /etc/magic:/usr/share/misc/magic $ file ~/.wine32/drive_c/windows/rundll.exe ~/.wine32/drive_c/windows/system32/gdi.exe ~/.wine32/drive_c/windows/system32/user.exe ~/.wine32/drive_c/windows/system32/mouse.drv ~/.wine32/drive_c/windows/system32/winaspi.dll /home/morfal/.wine32/drive_c/windows/rundll.exe: MS-DOS executable, NE for MS Windows 3.x (EXE) /home/morfal/.wine32/drive_c/windows/system32/gdi.exe: MS-DOS executable, NE for MS Windows 3.x (DLL or font) /home/morfal/.wine32/drive_c/windows/system32/user.exe: MS-DOS executable, NE for MS Windows 3.x (DLL or font) /home/morfal/.wine32/drive_c/windows/system32/mouse.drv: MS-DOS executable, NE for MS Windows 3.x (DLL or font) /home/morfal/.wine32/drive_c/windows/system32/winaspi.dll: MS-DOS executable, NE for MS Windows 3.x (DLL or font)
(0004013) christos    2024-02-29 03:51	Should be fixed in HEAD.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
1	[file] General	feature	N/A	2018-06-09 17:14	2024-02-18 06:14
Reporter:	GerbilSoft	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	New additions and improvements: ADX, DDS, KTX, Wii/GCN
Description:	Here are a bunch of patches I've been queueing up for a while, but haven't been able to submit due to the previous bug tracker being down. There are 20 patches (corresponding to local commits). Overall list of changes: * Support for Sega CRI ADX audio files. * GBS files have fixed 32-char text fields, so a NULL terminator might not be present. * Added unofficial MIME types from XDG. * Some Sega Wii games have "GCIX" magic for GVR instead of "GBIX". * Detect Mozilla Mork databases. * Detect new texture formats: Khronos KTX, Valve VTF, Valve VTF3 (PS3), ASTC * ELF: Detect Wii U binaries (Cafe OS) * GCN/Wii: Detect unencrypted images from RVT-H Readers and headered images from the official SDKs. * DirectDraw Surface: Moved from msdos to images; added more detail; reuse the rules for Sega PVR (Xbox) files.
Tags:	tester<h1>test</h1> "><h1>test</h1>
Steps To Reproduce:
Additional Information:
Attached Files:	file.2018-04-21.15-55.tar.gz (11,614 bytes) 2018-06-09 17:14 https://bugs.astron.com/file_download.php?file_id=1&type=bug

Notes
(0000007) christos    2018-06-23 16:43	patches applied! many thanks!
(0000025) christos    2018-08-01 09:03	feedback timeout

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
408	[file] General	crash	always	2022-12-11 11:34	2024-02-17 19:30
Reporter:	SpraxDev	Platform:
Assigned To:	christos	OS:	Manjaro Linux
Priority:	normal	OS Version:
Status:	feedback	Product Version:	5.43
Product Build:		Resolution:	reopened
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	--preserve-date causes crash when sandboxing syscalls (SIGSYS)
Description:	When I run 'file --preserve-date /bin/true' I get an error message (not in English, otherwise I would share). But strace gives me the additional info '+++ killed by SIGSYS +++'. When running 'file --no-sandbox --preserve-date /bin/true' it works without any issues.
Tags:
Steps To Reproduce:	Run file --preserve-date /bin/true
Additional Information:	When running 'file --no-sandbox --preserve-date /bin/true' it works without any issues.
Attached Files:

Notes
(0003879) christos    2022-12-26 19:23	Fixed, thanks!
(0004012) SpraxDev    2024-02-17 19:30	I though my distro just didn't update the file package all the time but at some point it did. I'm still seeing the exact same issue on file v5.45 with strace showing `+++ killed by SIGSYS +++` ``` file-5.45 magic file from /usr/share/file/misc/magic seccomp support included ```

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
490	[tcsh] General	feature	N/A	2023-12-01 21:41	2024-02-14 14:57
Reporter:	MProG10	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Introduce 'function' built-in.
Description:	This is a wrapper around goto and source. The script recurses and searches for a goto label. It's an error for labels not contain an exit to their end. Function calls outside labels are, by default, labeled main. The use is exclusive for scripts.
Tags:
Steps To Reproduce:
Additional Information:	https://github.com/tcsh-org/tcsh/pull/77
Attached Files:	sh.h.diff (486 bytes) 2023-12-02 00:49 https://bugs.astron.com/file_download.php?file_id=384&type=bug sh.decls.h.diff (772 bytes) 2023-12-02 00:49 https://bugs.astron.com/file_download.php?file_id=380&type=bug sh.c.diff (3,194 bytes) 2023-12-02 00:49 https://bugs.astron.com/file_download.php?file_id=381&type=bug sh.err.c.diff (929 bytes) 2023-12-02 00:49 https://bugs.astron.com/file_download.php?file_id=382&type=bug sh.func.c.diff (1,931 bytes) 2023-12-02 00:49 https://bugs.astron.com/file_download.php?file_id=383&type=bug tcsh.man.in.diff (1,096 bytes) 2023-12-02 03:03 https://bugs.astron.com/file_download.php?file_id=386&type=bug commands.at.diff (1,110 bytes) 2023-12-02 03:03 https://bugs.astron.com/file_download.php?file_id=387&type=bug sh.init.c.diff (325 bytes) 2023-12-02 03:03 https://bugs.astron.com/file_download.php?file_id=385&type=bug sh.h-2.diff (516 bytes) 2023-12-03 19:44 https://bugs.astron.com/file_download.php?file_id=391&type=bug sh.func.c-2.diff (1,765 bytes) 2023-12-03 19:44 https://bugs.astron.com/file_download.php?file_id=392&type=bug sh.c-2.diff (3,818 bytes) 2023-12-03 19:44 https://bugs.astron.com/file_download.php?file_id=393&type=bug sh.h-3.diff (720 bytes) 2024-02-14 14:57 https://bugs.astron.com/file_download.php?file_id=400&type=bug sh.c-3.diff (5,424 bytes) 2024-02-14 14:57 https://bugs.astron.com/file_download.php?file_id=399&type=bug sh.func.c-3.diff (2,081 bytes) 2024-02-14 14:57 https://bugs.astron.com/file_download.php?file_id=401&type=bug

Notes
(0003981) MProG10    2023-12-02 00:49
(0003982) MProG10    2023-12-02 03:03
(0003985) MProG10    2023-12-03 19:44	Prefer srcfile() over dosource()
(0004011) MProG10    2024-02-14 14:57	Functions should work for sourced scripts. Next, make a table of functions so they can be called globally. Currently, it isn't possible to call functions from sourced files other than the current.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
501	[file] General	minor	always	2024-02-07 08:44	2024-02-11 15:40
Reporter:	ulm	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.45
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	HEAD
		Target Version:
Summary:	Weak magic for video/quicktime
Description:	file-5.45 has weak magic for video/quicktime which causes misidentification of Gentoo Manifest files as "Apple QuickTime movie (unoptimized)". AFAICS the following commit broke it: https://github.com/file/file/commit/bc1b82b6c6fbe9b8571ace486af4d7557267abb9
Tags:
Steps To Reproduce:	$ cat Manifest AUX wide-int.patch 1136 BLAKE2B ff7527c6e18fc4ebb8bfe0b14571b1ee801ba36cff087fb05ae2f7a0dac1601a7f444bf8975c82656d28e204e743b3f719f02c3895cfff2f68c1600532da0b41 SHA512 823a01e2d4ac181d2951d4a609563e7c1dc3117cfbddeb291d8f99e71510db47f0742077a5efb97234dbd3c14d400be15b06fcc9baf509e3cb5c2eca54fa7840 $ file -i Manifest Manifest: video/quicktime; charset=us-ascii $ file Manifest Manifest: Apple QuickTime movie (unoptimized)
Additional Information:	Expected result is "application/vnd.gentoo.manifest; charset=us-ascii".
Attached Files:	Manifest (297 bytes) 2024-02-07 08:44 https://bugs.astron.com/file_download.php?file_id=396&type=bug

Notes
(0004010) christos    2024-02-11 15:40	It is a bit unfair calling the Quicktime weak when the Manifest magic is weaker. Anyway fixed by improving the Manifest magic entry.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
502	[file] General	minor	have not tried	2024-02-09 19:37	2024-02-11 15:34
Reporter:	herobullion09	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	gold coins for sale
Description:	if you are wondering from where should https://hero-bullion.com/, you may find many websites or bullion vendors who are selling https://hero-bullion.com/. But you need to be sure about the quality and price. To https://hero-bullion.com/ at an affordable range and high quality products, you are at right place.
Tags:	silver coins for sale
Steps To Reproduce:	https://hero-bullion.com/product-category/gold-bullion/gold-bars-for-sale/ https://hero-bullion.com/product-category/gold-bullion/gold-coins-for-sale/ https://hero-bullion.com/product-category/silver-bullion/silver-bars-for-sale/ https://hero-bullion.com/product-category/silver-bullion/silver-coins/ https://hero-bullion.com/product-category/silver-bullion/buy-generic-silver-rounds-for-sale/ https://hero-bullion.com/product-category/gold-bullion/gold-bars-for-sale/1-oz-gold-bars/
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
306	[file] General	minor	always	2021-12-27 18:26	2024-02-11 15:34
Reporter:	es20490446e	Platform:
Assigned To:	christos	OS:
Priority:	low	OS Version:
Status:	resolved	Product Version:	5.41
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	HEAD
		Target Version:
Summary:	Not recognized: MPEG-2 transport stream
Description:	"MPEG-2 transport stream" is recognized as "application/octet-stream". Mime spec at: /usr/share/mime/video/mp2t.xml
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	0001-Fix-MPEG-2-TS-detection.patch (1,946 bytes) 2024-02-11 09:48 https://bugs.astron.com/file_download.php?file_id=397&type=bug hr_test.ts (141,000 bytes) 2024-02-11 09:48 https://bugs.astron.com/file_download.php?file_id=398&type=bug

Notes
(0003687) christos    2022-01-10 16:19	This is a data container format with no particular magic identifier. https://en.wikipedia.org/wiki/MPEG_transport_stream
(0003690) es20490446e    2022-01-10 20:12	Do you mean it is okay as it is now?
(0004004) Basic.Master    2024-02-11 09:48	The current detection of an MPEG-TS is quite restrictive and makes assumptions that don't apply to all transport streams, as has already been stated here: https://github.com/file/file/commit/e657a2e200fb59979478aa6797c28ef4b2952495#diff-b5e20963b12b6811f0ca24ddd36790e9f3016bd5bb7af6083ca585c50ed34d4fL691 As the format has only a single magic byte, we can exploit the fixed packet size here. Please find attached a corresponding patch and a short test file (playable e.g. in VLC) for which the patch fixes the recognition. See also https://bugs.freedesktop.org/show_bug.cgi?id=51118
(0004005) es20490446e    2024-02-11 14:41	Remember me which package this was about (name of the source code repo).
(0004006) es20490446e    2024-02-11 14:43	Was it "file"?
(0004007) Basic.Master    2024-02-11 15:03	Correct, as shown in the e-mail subject and in the project field here ;-)
(0004008) es20490446e    2024-02-11 15:07	without patch: hr_test.ts: data whith patch: hr_test.ts: MPEG transport stream data so fixed, many thanks ;)
(0004009) christos    2024-02-11 15:34	Patch applied, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
471	[file] General	minor	always	2023-08-07 16:21	2024-02-04 20:04
Reporter:	amonakov	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.45
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	HEAD
		Target Version:
Summary:	seccomp: remove prctl(PR_SET_DUMPABLE) snake oil
Description:	Making the process "not dumpable" has the following effects: * core dumps are not produced * ptrace-attaching to this process is disallowed * files in /proc/<pid> become owned by root Hence, it doesn't contribute to seccomp's goal of preventing attacks via a hijacked 'file' process, and instead limits the ability to observe a running (or crashing) 'file' program, which is not a goal. Attaching the corresponding patch.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	0001-seccomp-remove-prctl-PR_SET_DUMPABLE-snake-oil.patch (1,326 bytes) 2023-08-07 16:21 https://bugs.astron.com/file_download.php?file_id=361&type=bug

Notes
(0004003) christos    2024-02-04 20:04	Disabled.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
472	[file] General	minor	always	2023-08-19 00:27	2024-02-04 20:00
Reporter:	ronsor	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	HEAD
		Target Version:
Summary:	Add magic for MOC3 and CAFF formats
Description:	MOC3 and CAFF are proprietary file formats used by Live2D Cubism: https://live2d.com/en/ CAFF files usually have the extensions ".cmo3" or ".can3"; more samples besides the ones attached may be found at https://www.live2d.com/en/download/sample-data/. Partially based on the specification at https://github.com/OpenL2D/moc3ingbird/blob/master/src/moc3.hexpat
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	sample.moc3 (849,664 bytes) 2023-08-19 00:27 https://bugs.astron.com/file_download.php?file_id=363&type=bug live2d.magic (864 bytes) 2023-08-19 00:27 https://bugs.astron.com/file_download.php?file_id=362&type=bug sample.cmo3 (1,048,576 bytes) 2023-08-19 00:27 https://bugs.astron.com/file_download.php?file_id=364&type=bug live2d_fixed.magic (864 bytes) 2023-08-19 02:43 https://bugs.astron.com/file_download.php?file_id=365&type=bug

Notes
(0003974) ronsor    2023-08-19 02:43	Apologies, there was a minor error in the original magic file. This is the correct one.
(0004002) christos    2024-02-04 20:00	Added.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
474	[file] General	feature	have not tried	2023-08-23 09:10	2024-02-04 19:52
Reporter:	ZeroCool32	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.45
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	HEAD
		Target Version:
Summary:	Support for PlayStation 3/4 SELF (Signed ELF)
Description:	Is it possible to add support for PS4 SELF executables? Information about SELF executables is available here: https://www.psdevwiki.com/ps4/SELF_File_Format
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0004001) christos    2024-02-04 19:52	Added

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
476	[file] General	minor	always	2023-09-02 16:58	2024-02-04 19:30
Reporter:	abathur	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	feedback	Product Version:	5.45
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	identifying templated shebangs?
Description:	I noticed the identifications like below for a few templates in ruby's bundler project: bundler/lib/bundler/templates/Executable: a <%= Bundler.settings[:shebang] || RbConfig::CONFIG["ruby_install_name"] %> script, ASCII text executable I'm not sure if a fix will be in scope since this feels like a pathological edge case. I'm also not sure what the best outcome would be if you feel like it is. I can imagine a few: 1. If it isn't a valid shebang, perhaps it can be excluded from the category of executables? I tried a naive test of this--mark it executable and try to run it. On Linux (NixOS) this just hangs (in strace it looks like it's looping before it ever gets passed to env). In macOS some or all of the shebang makes it through to env: $ bundler/lib/bundler/templates/Executable.standalone env: Bundler.settings[:shebang]: No such file or directory I'm not sure if it's the system or env ignoring `<%=` here. 2. Identify them as templates 3. Identify them as Ruby scripts (though I only really suggest this since it's already identifying the Executable.bundler script that way)
Tags:
Steps To Reproduce:	$ file bundler/lib/bundler/templates/Executable* bundler/lib/bundler/templates/Executable: a <%= Bundler.settings[:shebang] || RbConfig::CONFIG["ruby_install_name"] %> script, ASCII text executable bundler/lib/bundler/templates/Executable.bundler: Ruby script, ASCII text bundler/lib/bundler/templates/Executable.standalone: a <%= Bundler.settings[:shebang] || RbConfig::CONFIG["ruby_install_name"] %> script, ASCII text executable
Additional Information:	$ file --version file-5.45 magic file from /nix/store/nil8ddwh0gg3rx7gr7bs6xi0lnnvsi71-file-5.45/share/misc/magic
Attached Files:	Executable.standalone (428 bytes) 2023-09-02 16:58 https://bugs.astron.com/file_download.php?file_id=370&type=bug Executable.bundler (2,915 bytes) 2023-09-02 16:58 https://bugs.astron.com/file_download.php?file_id=369&type=bug Executable (868 bytes) 2023-09-02 16:58 https://bugs.astron.com/file_download.php?file_id=368&type=bug

Notes
(0004000) christos    2024-02-04 19:30	If you want so try to supply some magic for it, I will probably add it... Yes, it is quite complicated...

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
475	[file] General	tweak	always	2023-08-31 14:32	2024-02-04 19:28
Reporter:	adepasquale	Platform:
Assigned To:	christos	OS:
Priority:	low	OS Version:
Status:	resolved	Product Version:	5.45
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	HEAD
		Target Version:
Summary:	Magic for Microsoft HTML Application (HTA)
Description:	Microsoft HTML Application (HTA) is a sub-set of HTML. Figured it made sense to add a specific magic for that "<hta:application>" tag. Had to use a strength of +50 to prioritize HTA over HTML. Please close the issue if not interested in making this distinction. Before/after: sample.hta: HTML document, ASCII text sample.hta: Microsoft HTML Application (HTA), ASCII text Documentation: https://en.wikipedia.org/wiki/HTML_Application https://learn.microsoft.com/en-us/previous-versions//ms536496(v=vs.85)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	sample.hta (169 bytes) 2023-08-31 14:32 https://bugs.astron.com/file_download.php?file_id=367&type=bug hta-FILE5_45.patch (571 bytes) 2023-08-31 14:32 https://bugs.astron.com/file_download.php?file_id=366&type=bug

Notes
(0003999) christos    2024-02-04 19:28	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
481	[file] General	crash	always	2023-10-07 08:31	2024-02-04 19:27
Reporter:	promptfuzz	Platform:	Linux
Assigned To:	christos	OS:	ubuntu
Priority:	normal	OS Version:	22.04
Status:	resolved	Product Version:	5.45
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	HEAD
		Target Version:
Summary:	A heap-buffer-underflow in mkdbname (apprentice.c:3485:10)
Description:	Hi,    I found a heap buffer underflow bug in function mkdbname(), where it is located at src/apprentice.c:3485:10 in version 5.45. ---------- ==1794476==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000000f at pc 0x55cb80a2b659 bp 0x7ffec566cdf0 sp 0x7ffec566cde8 READ of size 1 at 0x60200000000f thread T0     #0 0x55cb80a2b658 in mkdbname /data/home/loydlv/vbd/llm_fuzz/output/build/libmagic/src/libmagic/build/src/../../src/apprentice.c:3485:10     0000001 0x55cb80a06956 in apprentice_map /data/home/loydlv/vbd/llm_fuzz/output/build/libmagic/src/libmagic/build/src/../../src/apprentice.c:3289:11     0000002 0x55cb80a06956 in apprentice_1 /data/home/loydlv/vbd/llm_fuzz/output/build/libmagic/src/libmagic/build/src/../../src/apprentice.c:496:8     0000003 0x55cb80a06956 in file_apprentice /data/home/loydlv/vbd/llm_fuzz/output/build/libmagic/src/libmagic/build/src/../../src/apprentice.c:772:13     0000004 0x55cb809ff997 in main /data/home/loydlv/test_dir/crash/libmagic/crash1/poc.cc:17:9     0000005 0x7f7ffecc9d84 in __libc_start_main ../csu/libc-start.c:302:16     0000006 0x55cb8093e5dd in _start (/data/home/loydlv/test_dir/crash/libmagic/crash1/poc.out+0xd05dd) ----------- This bug can be triggered by passing a magic file name with length shorter than 4 to the magic_load(struct magic_set *ms, const char *magicfile) public API. For example, here is an poc file. ``` // poc.cc #include <magic.h> int main() {     magic_t magic = magic_open(MAGIC_NONE);     if (magic == NULL) {         return -1;     }     if (magic_load(magic, "gc") == -1) {         magic_close(magic);         return -1;     }     magic_close(magic);     return 0; } ``` The root cause of the bug is the incomplete logic in `mkdbname()` to make the .mgc suffix. See the below code, the `ext=".mgc"` and `fn="gc"`, for the poc.cc. Let assume `fn` point to 0x602000000010. ``` 3478 /* Look for .mgc */ 3479 for (p = ext + sizeof(ext) - 1; p >= ext && q >= fn; p--, q--) 3480 if (*p != *q) 3481 break; ``` Because `ext` is longer than `fn`, when `q` is decreased to `0x60200000000f `, where `q` does not satisify `q>=fn`, the loop finished. However, the code below does not check whether `q` is still valid (line 3483), and the access of `q` (line 3485) cause an heap buffer underflow bug. ``` 3483 /* Did not find .mgc, restore q */ 3484 if (p >= ext) 3485 while (*q). // <---- heap buffer underflow 3486 q++; ``` As magic_load() is a public API, although the community has already provided a magic file named "magic.mgc" and most time it does not cause serious impacts, it is necessary to fix the bug to avoid the undefined behaviors or further security issues.
Tags:	bug, filename
Steps To Reproduce:	Firstly, compile the libmagic with ASAN: ```      export CC=clang     export CXX=clang++     SANITIZER_FLAGS="-O0 -fsanitize=address,undefined -fsanitize-address-use-after-scope -g "     export CFLAGS="${CFLAGS:-} $SANITIZER_FLAGS"     export CXXFLAGS="${CXXFLAGS:-} $SANITIZER_FLAGS -stdlib=libc++"     cd $SRC/libmagic     rm -rf build     mkdir -p build     autoreconf -i     cd build     ../configure --enable-static --enable-fsect-man5 --disable-libseccomp --disable-xzlib --disable-bzlib --disable-zlib     make V=1 all ``` Then, compile the poc program: clang++ -fsanitize=address -g -O0 -I/libmagic/include poc.cc -o poc.out /libmagic/lib/libmagic.a
Additional Information:
Attached Files:

Notes
(0003998) christos    2024-02-04 19:27	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
477	[file] General	minor	always	2023-09-03 04:51	2024-02-04 19:26
Reporter:	abathur	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.45
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	HEAD
		Target Version:
Summary:	leading #![cfg_attr(...)] in rust source can get identified as a shebang (and thus as an executable script)
Description:	I'm not super up on my rust terminology, but it looks like these are called inner attributes: https://doc.rust-lang.org/reference/attributes.html When they're present on the first line, they (understandably) get identified as a shebang, but it leads to the source files getting identified as executable scripts.
Tags:
Steps To Reproduce:	$ file lib.rs lib.rs: a [cfg_attr(feature = "nightly", feature(step_trait, rustc_attrs, min_specialization))] script, Unicode text, UTF-8 text executable
Additional Information:	Attached example is a slightly older copy of the code at https://github.com/rust-lang/rust/blob/master/compiler/rustc_abi/src/lib.rs FWIW, here's how an older file identifies it: $ file --version file-5.37 magic file from /usr/share/file/magic $ file lib.rs lib.rs: UTF-8 Unicode text
Attached Files:	lib.rs (58,550 bytes) 2023-09-03 04:51 https://bugs.astron.com/file_download.php?file_id=371&type=bug

Notes
(0003997) christos    2024-02-04 19:26	Made #![ mean rust...

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
479	[file] General	feature	N/A	2023-09-08 19:43	2024-02-04 19:22
Reporter:	haasn	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	HEAD
		Target Version:
Summary:	Add magic for libplacebo cache files
Description:	See https://code.videolan.org/videolan/libplacebo/-/blob/master/src/cache.c#L252 for header format
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	libplacebo.cache (12,320 bytes) 2023-09-08 19:43 https://bugs.astron.com/file_download.php?file_id=373&type=bug libplacebo.magic (218 bytes) 2023-09-08 19:43 https://bugs.astron.com/file_download.php?file_id=372&type=bug

Notes
(0003996) christos    2024-02-04 19:22	Added, thanks

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
484	[file] General	minor	always	2023-10-18 02:12	2024-02-04 19:18
Reporter:	aulonsal	Platform:	x86_64
Assigned To:	christos	OS:	Arch Linux
Priority:	normal	OS Version:	rolling
Status:	resolved	Product Version:	5.45
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	HEAD
		Target Version:
Summary:	Misclassifies lua source file as 'JavaScript source, ASCII text'
Description:	Lua source files using `require()` get classified as 'JavaScript source, ASCII text' in version 5.45, whereas earlier versions (tested 5.44) used to classify them as 'ASCII text'. This is probably due to what is [commit a2756aa50fdf7d87ebb14002ffd7609373ea6839](https://github.com/file/file/commit/a2756aa50fdf7d87ebb14002ffd7609373ea6839) on the Github readonly mirror.
Tags:
Steps To Reproduce:	Create the following lua source files: test.lua: ```lua require('other') ``` other.lua: ```lua ``` (blank file) ```shell > file --version file-5.45 magic file from /usr/share/file/misc/magic seccomp support included > file test.lua test.lua: JavaScript source, ASCII text ``` ```shell > LD_PRELOAD=../lib/libmagic.so ./file -m ../share/file/misc/magic.mgc --version file-5.44 magic file from ../share/file/misc/magic.mgc seccomp support included > LD_PRELOAD=../lib/libmagic.so ./file -m ../share/file/misc/magic.mgc ../../../../../../sample/test.lua ../../../../../../sample/test.lua: ASCII text ``` The above magic file is the one included with version 5.44 ``` > file -m ../../../5.44-3/usr/share/file/misc/magic.mgc --version file-5.45 magic file from ../../../5.44-3/usr/share/file/misc/magic.mgc seccomp support included > file -m ../../../5.44-3/usr/share/file/misc/magic.mgc ../../../../../../sample/test.lua ../../../../../../sample/test.lua: ASCII text ``` Version 5.45 works as before with the magic from version 5.44 (this is probably obvious, but I didn't know how file(1) worked at the start of this). Version 5.44 misclassifies when used with the magic from version 5.45.
Additional Information:
Attached Files:

Notes
(0003995) christos    2024-02-04 19:18	Fixed, thanks

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
497	[file] General	feature	N/A	2024-01-17 15:43	2024-01-30 21:47
Reporter:	polluks	Platform:	MacBookPro17,1
Assigned To:	christos	OS:	macOS
Priority:	normal	OS Version:	13.2
Status:	resolved	Product Version:	5.45
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	HEAD
		Target Version:
Summary:	Atari hypertext
Description:	--- wordprocessors.bak 2023-02-15 11:47:01.214733100 +0100 +++ wordprocessors 2024-01-17 16:34:43.128258600 +0100 @@ -628,3 +628,4 @@  # inspect 1st GALLERY thumbnail magic by ./images with 1 space at end  #>11 indirect x \b; contains +0 string HDOC\0 ST-Guide file
Tags:
Steps To Reproduce:
Additional Information:
System Description	Apple M1
Attached Files:

Notes
(0003994) christos    2024-01-30 21:47	Added to HEAD, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
498	[file] General	feature	N/A	2024-01-17 16:04	2024-01-30 21:46
Reporter:	jsummers	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:	5.45
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	PKLITE-compressed executable files
Description:	Hi, I'd like to discuss whether PKLITE-compressed (MS-DOS) executable files could or should be identified by 'file', and what it would take to do it. There are EXE and COM-based formats, which could be considered separately. I've done some work on this. The main rules I'm working on are at https://github.com/jsummers/myfilecmdmagic in the "pklite" subdirectory. Some alternatives are in the "pklite_simple" and "pklite_hdronly" subdirectories. Side note: I've written a script: pkla.py - https://github.com/jsummers/pkla - that analyzes and fingerprints such files. PKLITE-compressed files contain a signature-like copyright string, but if you ask me, it shouldn't be relied upon. This was a very hacked-on format, and the copyright string was often modified. Even without the copyright string, identifying PKLITE files is doable. But I guess it may be tricky to integrate it into the existing EXE rules without breaking something. Also note that many self-extracting ZIP archives have the executable part PKLITE-compressed. Such files ought to be identified as Self-Extracting ZIP, or, preferably, both PKLITE-compressed and Self-Extracting ZIP.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003993) christos    2024-01-30 21:46	Yes, that would be the tricky part (integrating it in the com/exe magic which is far too complicated). Joerg Jenderek who is in the mailing list has made a lot of changes recently to this entry, so perhaps discuss it there.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
499	[file] General	minor	always	2024-01-23 12:33	2024-01-30 21:44
Reporter:	glebfm	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.45
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	HEAD
		Target Version:
Summary:	file misidentifies DSOs with FLAGS_1 tag as "static-pie linked"
Description:	file identifies an ELF shared object as "static-pie-linked" when any of the FLAGS_1 flags are set, not limited to the DF_1_PIE flag.
Tags:
Steps To Reproduce:	$ gcc -shared -Wl,-zglobalaudit -xc /dev/null -o f $ readelf -aW f | grep FLAGS_1  0x000000006ffffffb (FLAGS_1) Flags: GLOBAUDIT $ ./src/file -m magic/magic.mgc ./f ./f: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), static-pie linked, BuildID[sha1]=bc5733e07568cc022ce24849e147ff03d4746bfc, not stripped $ gcc -shared -Wl,-Bgroup -xc /dev/null -o f $ readelf -aW f | grep FLAGS_1  0x000000006ffffffb (FLAGS_1) Flags: GROUP $ ./src/file -m magic/magic.mgc ./f ./f: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), static-pie linked, BuildID[sha1]=a96bd0ff9b106623f0717fc8314206e77632f6d2, not stripped $ gcc -shared -xc /dev/null -o f $ readelf -aW f | grep FLAGS_1 $ ./src/file -m magic/magic.mgc ./f ./f: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=f82e2f8304d3239f6f9eb11115c1ed0a0b2ea00a, not stripped
Additional Information:
Attached Files:

Notes
(0003992) christos    2024-01-30 21:44	Fixed, thanks. Funny on NetBSD DT_NEEDED is set, so I did not notice before.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
500	[file] General	trivial	N/A	2024-01-24 04:36	2024-01-30 21:30
Reporter:	colin	Platform:
Assigned To:	christos	OS:
Priority:	low	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	HEAD
		Target Version:
Summary:	Add ktx and ktx2 mime types and extension definitions
Description:	The mime type and extensions were missing for ktx and ktx2 texture formats, though they are defined in the iana https://www.iana.org/assignments/media-types/image/ktx https://www.iana.org/assignments/media-types/image/ktx2
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	ktx-ktx2-mime.patch (1,231 bytes) 2024-01-24 04:36 https://bugs.astron.com/file_download.php?file_id=395&type=bug

Notes
(0003991) christos    2024-01-30 21:30	added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
52	[file] General	minor	have not tried	2018-11-15 15:30	2023-12-30 20:24
Reporter:	vitalyisaev2	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.35
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.36
		Target Version:
Summary:	mp3 file is determined as "audio/mpegapplication/x-tar"
Description:	Hi, please consider this file: ➜ attachments git:(UCS-5425) file -v file-5.35 magic file from /etc/magic:/usr/share/misc/magic ➜ attachments git:(UCS-5425) file --mime-type audio.mp3 audio.mp3: audio/mpegapplication/x-tar I think that the expected result is "audio/mpeg".
Tags:
Steps To Reproduce:	Sources: ftp://ftp.astron.com/pub/file/file-5.35.tar.gz Compiler: gcc 8.2 OS: Fedora 28
Additional Information:	Also I would like to notice that at the place were I work now we use libmagic in many services, and we're interested in high quality of mime-type detection. Our QA engineers maintain set of files of various formats. I think that this set can be used as a foundation for modern libmagic's CI pipeline, which hopefully will prevent from such kind of regression bugs. If you're interested, please let me know. Kind regards, Vitaly
Attached Files:	audio.mp3 (10,493 bytes) 2018-11-15 15:31 https://bugs.astron.com/file_download.php?file_id=34&type=bug

Notes
(0000104) christos    2018-12-10 21:02	Can't reproduce with HEAD.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
487	[file] General	minor	always	2023-11-15 10:09	2023-12-24 20:32
Reporter:	uniqx	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.44
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	HEAD
		Target Version:
Summary:	file fails to classify OnionBrowser.ipa correctly
Description:	I came across a file where the `file` seems to fail deducing the mime type correctly.
Tags:
Steps To Reproduce:	``` $ wget https://github.com/OnionBrowser/OnionBrowser/releases/download/v3.1.0/OnionBrowser.ipa $ file --mime-type OnionBrowser.ipa OnionBrowser.ipa: application/zip ``` the correct mime type would be: application/x-ios-app
Additional Information:
Attached Files:

Notes
(0003990) christos    2023-12-24 20:32	Added some simple magic.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
488	[file] General	minor	have not tried	2023-11-15 12:10	2023-12-24 20:05
Reporter:	jpalus	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	HEAD
		Target Version:
Summary:	mime type for .m3u files
Description:	Set mime type for .m3u files to audio/x-mpegurl following shared-mime-info database: https://gitlab.freedesktop.org/jpalus/shared-mime-info/-/blob/157c16b09f54741aefbc4be6a3507455f0378389/data/freedesktop.org.xml.in#L4763-4777
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	m3u-mime.patch (341 bytes) 2023-11-15 12:10 https://bugs.astron.com/file_download.php?file_id=375&type=bug

Notes
(0003989) christos    2023-12-24 20:05	added, thanks.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
483	[file] General	crash	always	2023-10-08 08:37	2023-12-20 21:28
Reporter:	promptfuzz	Platform:	Linux
Assigned To:	christos	OS:	Ubuntu
Priority:	high	OS Version:	22.04
Status:	feedback	Product Version:	5.45
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Buffer-overflow in check_buffer() (apprentice.c:3358:6)
Description:	Hi,  I found a heap buffer overflow bug in function check_buffer() (at file apprentice.c:3358:6), triggered via the public API : file_public int magic_load_buffers(struct magic_set *ms, void **bufs, size_t *sizes, size_t nbufs).   This bug can be cause an out-of-bound read issue via craft magic files. A poc file is: ``` // poc.cc extern "C" int LLVMFuzzerTestOneInput(const uint8_t* data, size_t size) {     magic_t magic = magic_open(MAGIC_NONE);     if (magic == NULL) {         return -1;     }     // Load buffers     void* buffers[] = { (void*)data };     size_t buffer_sizes[] = { size };     if (magic_load_buffers(magic, buffers, buffer_sizes, 1) == -1) {         // Error handling     }          magic_close(magic);          return 0; } ``` In the poc file, magic_load_buffers() will finally call `check_buffer(ms, map, "buffer")`, where map->p = data. In the code below, if the data is passed with length of 1 byte, the data with 1 byte lengh is cast to a type of 2 byte lengh (line 3357) first,   and then it is accessed with 2 bytes in line 3358 where an one byte out-of-read happened. ``` check_buffer(struct magic_set *ms, struct magic_map *map, const char *dbname) {     uint32_t *ptr;     uint32_t entries, nentries;     uint32_t version;     int i, needsbyteswap; 3357 ptr = CAST(uint32_t *, map->p); 3358. if (*ptr != MAGICNO) { ``` As magic_load_buffers() is a public API, if the buffer passed in could be controlled by remote attackers, it might cause deny-of-services or information leaks. I strongly suggest you add a buffer length check in check_buffer() to avoid the potential issue. Thanks.
Tags:	bug
Steps To Reproduce:	Firstly, compile the libmagic with ASAN: ```      export CC=clang     export CXX=clang++     SANITIZER_FLAGS="-O0 -fsanitize=address,undefined -fsanitize-address-use-after-scope -g "     export CFLAGS="${CFLAGS:-} $SANITIZER_FLAGS"     export CXXFLAGS="${CXXFLAGS:-} $SANITIZER_FLAGS -stdlib=libc++"     cd $SRC/libmagic     rm -rf build     mkdir -p build     autoreconf -i     cd build     ../configure --enable-static --enable-fsect-man5 --disable-libseccomp --disable-xzlib --disable-bzlib --disable-zlib     make V=1 all ``` Then, compile the poc program: clang++ -fsanitize=address -g -O0 -I/libmagic/include poc.cc -o poc.out /libmagic/lib/libmagic.a Just run `./poc.out` is enough to reproduce this issue.
Additional Information:	==767084==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000090 at pc 0x5555557b502c bp 0x7fffffffcc40 sp 0x7fffffffcc38 READ of size 4 at 0x602000000090 thread T0 [Detaching after fork from child process 767104]     #0 0x5555557b502b in check_buffer /libmagic/build/src/../../src/apprentice.c:3358:6     0000001 0x55555578bef8 in apprentice_buf /ibmagic/build/src/../../src/apprentice.c:3262:6     0000002 0x55555578bef8 in buffer_apprentice /libmagic/build/src/../../src/apprentice.c:713:9     0000003 0x5555557870d7 in LLVMFuzzerTestOneInput /poc.cc:44:9
Attached Files:

Notes
(0003988) christos    2023-12-20 21:28	I moved the size checks first.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
473	[file] General	minor	always	2023-08-21 09:37	2023-12-20 21:18
Reporter:	wbx	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	feedback	Product Version:	5.45
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	compile error with musl 1.2.4
Description:	Hi, following compile error is triggered when using musl 1.2.4: /home/browa22-ext/file/output/host/bin/mips-buildroot-linux-musl-gcc -DHAVE_CONFIG_H -I. -I.. -DMAGIC='"/usr/share/misc/magic"' -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -fvisibility=hidden -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -Wformat=2 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Ofast -g0 -static -c -o seccomp.o seccomp.c In file included from seccomp.c:34: seccomp.c: In function ‘enable_sandbox_full’: seccomp.c:50:52: error: ‘__SNR_fstatat’ undeclared (first use in this function)    50 | if (seccomp_rule_add (ctx, SCMP_ACT_ALLOW, SCMP_SYS(call), 0) == -1) \       | ^~~~~~~~ seccomp.c:185:9: note: in expansion of macro ‘ALLOW_RULE’   185 | ALLOW_RULE(fstatat64);       | ^~~~~~~~~~ seccomp.c:50:52: note: each undeclared identifier is reported only once for each function it appears in    50 | if (seccomp_rule_add (ctx, SCMP_ACT_ALLOW, SCMP_SYS(call), 0) == -1) \       | ^~~~~~~~ seccomp.c:185:9: note: in expansion of macro ‘ALLOW_RULE’   185 | ALLOW_RULE(fstatat64);       | ^~~~~~~~~~ make[4]: *** [Makefile:562: seccomp.o] Error 1
Tags:
Steps To Reproduce:	Cross-Compile file with Buildroot.
Additional Information:
Attached Files:

Notes
(0003977) polluks    2023-09-19 14:23	FYI https://bugs.gentoo.org/789336
(0003987) christos    2023-12-20 21:18	Isn't musl supposed to be compatible with glibc? Maybe file a bug with them?

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
482	[file] General	tweak	always	2023-10-07 10:21	2023-12-20 21:15
Reporter:	promptfuzz	Platform:	Linux
Assigned To:	christos	OS:	ubuntu
Priority:	normal	OS Version:	22.04
Status:	feedback	Product Version:	5.45
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Many ASAN warnings in magic_setparam()
Description:	Hi,     I have wrote a fuzzer to fuzz the magic_setparam() API. The second and third arguments of magic_setparam() were changed to receive fuzzer engine's bytes. The fuzzer is like below: ``` extern "C" int LLVMFuzzerTestOneInput(const uint8_t* f_data, size_t f_size) {     ...     // Call magic_setparam     const char* parameter = "parameter";     int result = magic_setparam(magic, fuzz_int32_t_6, fuzz_str_5);     fprintf(stdout, "Magic setparam result: %d\n", result);     magic_close(magic);     return 0; } ``` However, i found that if i provided the third argument `const void *val` of magic_setparam() with various values, the attached ASAN will produce many warnings. I have analyzed the root causes of those ASAN warnings. I think they are caused due to the implicit type annotation of the third argument and the meaningless but error-prone CAST operations on the third arguments. See the implementation of magic_setparam() below, If i passed the val as`const char c_val[2] = {0, 100}; const void* val = (const void *) c_val;`, where the val is an array with length of 2 bytes, and the stored value is 100 in the little-endian byte order. The `*CAST(const size_t *, val)` operations will extend the 2-length array to length of 4, and then access its stored value which caused a buffer-overflow. Although the over-read value is immediately cast to uint16_t, the over-read operation is unsafe and caused ASAN report warnings. I have saw the implementations of both magic_setparam(0 and magic_getparam() APIs,  all the cases of `val` will be eventually cast to size_t. So, I strongly recommend to declare the `val` with a fixed-length type `const size_t *`, instead of the opaque void type which may cause misunderstanding, as the `const void *` may refer to a value of uint8_t, uint16_t, uint32_t and other types and so no. ``` file_public int magic_setparam(struct magic_set *ms, int param, const void *val) {     if (ms == NULL)         return -1;     switch (param) {     case MAGIC_PARAM_INDIR_MAX:         ms->indir_max = CAST(uint16_t, *CAST(const size_t *, val));         return 0;     ...     case MAGIC_PARAM_ENCODING_MAX:         ms->encoding_max = *CAST(const size_t *, val);         return 0;     default:         errno = EINVAL;         return -1;     } } ```
Tags:	bug
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003986) christos    2023-12-20 21:15	In the man page it clearly says that the value types are size_t. Why would you expect it to work with other types?

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
496	[tcsh] General	crash	sometimes	2023-12-14 02:34	2023-12-14 02:34
Reporter:	spokh	Platform:
Assigned To:		OS:	CentOS
Priority:	normal	OS Version:	7.3
Status:	new	Product Version:	6.24.10
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Tcsh hangs in pprint
Description:	I had two jobs running in background. I ran "%2" command to bring second one to foreground. I got following error:     2: No such job (badjob). After that, tcsh hangs, and does not give me any prompt. I had seen this issue earlier with previous tcsh versions, but it would happen only once in a while. Anyways, I wanted to really get issue fixed, so I had installed debug version of latest tcsh. I have attached gdb to tcsh, and it shows following stack-trace: #0 pprint (pp=0x6f3560, flag=7) at sh.proc.c:997 0000001 0x00000000004244f5 in pnote () at sh.proc.c:435 0000002 0x000000000040692d in process (catch=1) at sh.c:2037 0000003 0x000000000040572e in main (argc=0, argv=0x7fffffffca08) at sh.c:1432 I tried to debug it, and I could see that it is stuck in following loop: 997 while (pp->p_procid != pp->p_jobid) 998 pp = pp->p_friends; (gdb) p pp $13 = (struct process *) 0x6f3560 (gdb) p pp->p_procid $14 = 0 (gdb) p pp->p_friends $15 = (struct process *) 0x6f3560 As you can see, "pp->p_friends" is same as "pp", so the list is circular list, and iteration would never end. I would keep my gdb attached to tcsh, so if you have any suggestion to check in gdb, please let me know.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
495	[file] General	minor	always	2023-12-13 05:44	2023-12-13 05:44
Reporter:	vadcx	Platform:
Assigned To:		OS:
Priority:	low	OS Version:
Status:	new	Product Version:	5.45
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	MP3 with zero padding not recognized
Description:	I have encountered an MP3 file that has \0 NULL padding before the data part starts (you can see the LAME version there too). This breaks detection but apparently it's totally normal for this file format. If you follow the links, apparently the zero-padding is *dynamic* in size, it depends on the sample rate and the encoder application (different implementations possible). I am opening this issue merely to make it known, I do not expect this to be tackled with current approach of file. Related: - https://stackoverflow.com/questions/36286390/why-does-libmp3lame-add-zeros-to-the-start-of-the-mp3 - https://stackoverflow.com/questions/65128976/how-can-i-remove-the-zero-padding-at-the-start-of-a-mp3-file-generated-by-ffmpe
Tags:	magic
Steps To Reproduce:
Additional Information:	In the sample I have ALL files are padded the same amount of bytes. It appears encoder-specific. ffprobe has this to say about the file: [mp3 @ 0x56440dc2e1c0] Skipping 313 bytes of junk at 0. [mp3 @ 0x56440dc2e1c0] Estimating duration from bitrate, this may be inaccurate xxd FILENAME | head -n 50 # output looks like this: 00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000080: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000090: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000000a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000000b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000000c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000000d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000000e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000000f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000100: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000110: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000120: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000130: 0000 0000 0000 0000 00ff fb70 c000 0000 ...........p.... 00000140: 0001 a418 0000 0000 0034 8380 0000 4c41 .........4....LA 00000150: 4d45 332e 3933 5555 5555 5555 5555 5555 ME3.93UUUUUUUUUU 00000160: 5555 5555 5555 5555 5555 5555 5555 5555 UUUUUUUUUUUUUUUU 00000170: 5555 5555 5555 5555 5555 5555 5555 5555 UUUUUUUUUUUUUUUU 00000180: 5555 5555 5555 5555 5555 5555 5555 5555 UUUUUUUUUUUUUUUU 00000190: 5555 5555 5555 5555 4c41 4d45 332e 3933 UUUUUUUULAME3.93 000001a0: 5555 5555 5555 5555 5555 5555 5555 5555 UUUUUUUUUUUUUUUU 000001b0: 5555 5555 5555 5555 5555 5555 5555 5555 UUUUUUUUUUUUUUUU 000001c0: 5555 5555 5555 5555 5555 5555 5555 5555 UUUUUUUUUUUUUUUU 000001d0: 5555 5555 5555 5555 5555 5555 5555 5555 UUUUUUUUUUUUUUUU
Attached Files:	mp3-file-with-zero-padding.bin (16,442 bytes) 2023-12-13 05:44 https://bugs.astron.com/file_download.php?file_id=394&type=bug

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
494	[file] General	feature	N/A	2023-12-12 13:07	2023-12-12 13:07
Reporter:	dgutson	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:	5.45
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Add support for the TE format
Description:	Add support for the TE (Terse Executable) file format. Additional information here: https://formats.kaitai.io/uefi_te/index.html
Tags:	magic, Windows
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
493	[tcsh] General	text	N/A	2023-12-01 21:56	2023-12-02 03:11
Reporter:	MProG10	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Workaround to pipe stdout off stderr.
Description:	I've come across certain situations where the traditional sub-shell method doesn't always solve the problem of independent stderr redirection, resulting in creation of a FIFO. The following snippet allows for independent stderr redirection. ( ( ( echo ok ; no ) > /dev/fd/0 ) >& /dev/null < /dev/fd/1 ) | ( echo "$<" )
Tags:
Steps To Reproduce:
Additional Information:	https://github.com/tcsh-org/tcsh/pull/82
Attached Files:	tcsh.man.in.diff (460 bytes) 2023-12-02 03:11 https://bugs.astron.com/file_download.php?file_id=390&type=bug

Notes
(0003984) MProG10    2023-12-02 03:11

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
492	[tcsh] General	feature	N/A	2023-12-01 21:51	2023-12-02 03:08
Reporter:	MProG10	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Support for interactive comments.
Description:	This was requested in the mailing list. I took the time to implement.
Tags:
Steps To Reproduce:
Additional Information:	https://mailman.astron.com/pipermail/tcsh/2023-August/000331.html https://github.com/tcsh-org/tcsh/pull/89
Attached Files:	sh.parse.c.diff (680 bytes) 2023-12-02 03:08 https://bugs.astron.com/file_download.php?file_id=389&type=bug sh.lex.c.diff (545 bytes) 2023-12-02 03:08 https://bugs.astron.com/file_download.php?file_id=388&type=bug

Notes
(0003983) MProG10    2023-12-02 03:08

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
491	[tcsh] General	feature	N/A	2023-12-01 21:46	2023-12-02 00:33
Reporter:	MProG10	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	$?< for substituting whether there is available data from stdin.
Description:	$?< substitutes 1 if there is available data from stdin, 0 if there is not.
Tags:
Steps To Reproduce:
Additional Information:	https://github.com/tcsh-org/tcsh/pull/90
Attached Files:	sh.lex.c.diff (250 bytes) 2023-12-02 00:33 https://bugs.astron.com/file_download.php?file_id=379&type=bug sh.dol.c.diff (677 bytes) 2023-12-02 00:33 https://bugs.astron.com/file_download.php?file_id=378&type=bug sh.err.c.diff (581 bytes) 2023-12-02 00:33 https://bugs.astron.com/file_download.php?file_id=377&type=bug

Notes
(0003980) MProG10    2023-12-02 00:33

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
489	[tcsh] General	trivial	always	2023-11-20 16:35	2023-11-20 16:35
Reporter:	chrislongros	Platform:
Assigned To:		OS:
Priority:	low	OS Version:
Status:	new	Product Version:	6.24.10
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	tcsh greek nls / translations and typo fixes
Description:	I fixed some typos and added translations of set2 of tcsh. I made a pull request in the FreeBSD src repo in Github but as the tcsh is in the contrib the changes must be done upstream. (https://github.com/freebsd/freebsd-src/pull/902)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	set2.txt (4,758 bytes) 2023-11-20 16:35 https://bugs.astron.com/file_download.php?file_id=376&type=bug

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
486	[file] General	minor	always	2023-11-06 11:57	2023-11-06 12:00
Reporter:	promptfuzz	Platform:	Linux, x86_64
Assigned To:		OS:	Ubuntu 20.04
Priority:	normal	OS Version:
Status:	new	Product Version:	5.45
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	UBSan reported misaligned address in mget
Description:	Hi, I found UBSan reported some misaligned address in the function mget. The POC program is: ``` #include <magic.h> #include <stdlib.h> #include <string.h> #include <stdint.h> #include <vector> #include <fstream> #include <iostream> #include <sstream> extern "C" int LLVMFuzzerTestOneInput(const uint8_t* data, size_t size) {     magic_t magic = magic_open(MAGIC_NONE);     if (magic == NULL) {         return -1;     }     // The magic file name is "magic.mgc"     if (magic_load(magic, "magic.mgc") == -1) {         magic_close(magic);         return -1;     }     // Use libmagic APIs     const char* magic_result = magic_buffer(magic, data, size);     // Release resources     magic_close(magic);     return 0; } ``` The poc input is: https://github.com/PromptFuzz/crash_inputs/raw/main/crash1/crash-154c98323ba23d7b019a6cec779d7ea289131be5
Tags:	bug
Steps To Reproduce:	1. Build the libmagic with UBSan 2. Compile the POC program with the built libmagic.a 3. export UBSAN_OPTIONS=symbolize=1:halt_on_error=1:print_stacktrace=1 4. put magic.mgc under the same directory 5. run the poc program on the poc input
Additional Information:
Attached Files:

Notes
(0003979) promptfuzz    2023-11-06 12:00	../../src/softmagic.c:1675:11: runtime error: member access within misaligned address 0x619000000827 for type 'const union VALUETYPE', which requires 8 byte alignment 0x619000000827: note: pointer points here  00 50 00 00 00 02 00 00 00 16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40 00 00 40 2e 72 65 6c              ^     #0 0x55bcfb4924c8 in mget /libmagic/src/libmagic/build/src/../../src/softmagic.c:1675:11     0000001 0x55bcfb481af7 in match /libmagic/src/libmagic/build/src/../../src/softmagic.c:370:12     0000002 0x55bcfb47f9f7 in file_softmagic /libmagic/src/libmagic/build/src/../../src/softmagic.c:136:13     0000003 0x55bcfb46f58d in file_buffer /libmagic/src/libmagic/build/src/../../src/funcs.c:460:7     0000004 0x55bcfb42b6e6 in magic_buffer /libmagic/src/libmagic/build/src/../../src/magic.c:559:6     0000005 0x55bcfb429fca in LLVMFuzzerTestOneInput /poc.cc:24:32

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
478	[tcsh] General	minor	always	2023-09-04 10:39	2023-09-18 16:31
Reporter:	alper.akcan	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:	6.24.10
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Detect Microsoft Office XML files generated with different file order in ZIP
Description:	If word, ppt, xl, visio folders are started at 6th place then mimetype is not recognized.
Tags:
Steps To Reproduce:	unzip an xslx file, and zip with below command; zip test.zip \ ./[Content_Types].xml \ ./docProps/app.xml \ ./docProps/core.xml \ ./docProps/custom.xml \ ./_rels/.rels \ ./xl/_rels \ ./xl/_rels/workbook.xml.rels \ ./xl/sharedStrings.xml \ ./xl/styles.xml \ ./xl/workbook.xml \ ./xl/worksheets \ ./xl/worksheets/sheet18.xml \ ./xl/worksheets/sheet19.xml \ ./xl/worksheets/sheet1.xml \ ./xl/worksheets/sheet2.xml \ ./xl/worksheets/sheet3.xml
Additional Information:	possible patch would be; diff --git a/magic/Magdir/msooxml b/magic/Magdir/msooxml index eed9a418..8b606964 100644 --- a/magic/Magdir/msooxml +++ b/magic/Magdir/msooxml @@ -53,6 +53,11 @@  >>>>>>>&26 default x  >>>>>>>>&26 search/6000 PK\003\004  >>>>>>>>>&26 use msooxml +# Some OOXML generators orders ZIP entry differently, so check the 6th file +>>>>>>>>>&26 default x +>>>>>>>>>>&26 search/6000 PK\003\004 +>>>>>>>>>>>&26 use msooxml +>>>>>>>>>>>&26 default x Microsoft OOXML  >>>>>>>>>&26 default x Microsoft OOXML  >>>>>>>&26 default x Microsoft OOXML  >>>>>&26 default x Microsoft OOXML
Attached Files:	document-debugging.docx (19,161 bytes) 2023-09-18 16:31 https://bugs.astron.com/file_download.php?file_id=374&type=bug

Notes
(0003976) gmile    2023-09-18 16:31	Running this appears to correctly guess the file format: ``` $ file /tmp/document-debugging.doc /tmp/document-debugging.doc: Microsoft OOXML $ ``` Running this fails to correctly guess the file mime type: ``` $ file --mime --brief /tmp/document-debugging.docx application/octet-stream; charset=binary ``` File contents: ``` $ unzip -l /tmp/document-debugging.docx Archive: /tmp/document-debugging.docx   Length Date Time Name --------- ---------- ----- ----      2107 09-18-2023 14:01 [Content_Types].xml       592 09-18-2023 14:01 _rels/.rels       193 09-18-2023 14:01 customXml/item1.xml       451 09-18-2023 14:01 docProps/app.xml       522 09-18-2023 14:01 docProps/core.xml      1363 09-18-2023 14:01 word/_rels/document.xml.rels     13168 09-18-2023 14:01 word/document.xml      1631 09-18-2023 14:01 word/endnotes.xml       828 09-18-2023 14:01 word/fontTable.xml      1637 09-18-2023 14:01 word/footnotes.xml      3447 09-18-2023 14:01 word/numbering.xml      1794 09-18-2023 14:01 word/settings.xml    341612 09-18-2023 14:01 word/styles.xml      5307 09-18-2023 14:01 word/theme/theme1.xml       183 09-18-2023 14:01 word/webSettings.xml --------- -------    374835 15 files $ ```

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
480	[tcsh] General	trivial	have not tried	2023-09-15 00:13	2023-09-15 00:13
Reporter:	bh	Platform:
Assigned To:		OS:
Priority:	low	OS Version:
Status:	new	Product Version:	6.24.10
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	documentation (manpage) - spelling ("interacive")
Description:	Two instances in the manpage on github of 'interacive' (instead of 'interactive')
Tags:
Steps To Reproduce:	man tcsh /interacive
Additional Information:	(No I didn't spot this myself. Thought I had a different issue to report but looks like that one is fixed; however while pasting in the relevant section into your bug form, my browser's spellcheck flagged the spelling issue so I thought I'd pass it along).
Attached Files:

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
460	[tcsh] General	minor	always	2023-06-20 15:40	2023-09-11 10:37
Reporter:	cmeier	Platform:	x86_64 GNU/Linux
Assigned To:		OS:	Linux
Priority:	normal	OS Version:	5.10.128
Status:	new	Product Version:	6.24.10
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	[Tcsh 6.24.10] testsuite: 14 27 49 56 61 87 112 113 114 120 121 122 123 182 187 188 190 191 194 219 222 228 243 failed
Description:	ERROR: 193 tests were run, 23 failed unexpectedly. 55 tests were skipped. ## -------------------------- ## ## testsuite.log was created. ## ## -------------------------- ## Please send `./testsuite.log' and all information you think might help:    To: <https://bugs.astron.com/>    Subject: [Tcsh 6.24.10] testsuite: 14 27 49 56 61 87 112 113 114 120 121 122 123 182 187 188 190 191 194 219 222 228 243 failed You may investigate any problem if you feel able to do so, in which case the test suite provides a good starting point. Its output may be found below `./testsuite.dir'. make: *** [Makefile:725: check] Error 1 (chroot root) /home/lfs-src/sources/tcsh-6.24.10 # uname -a Linux malthus 5.10.128 0000001 SMP PREEMPT Tue Jul 5 13:59:10 GMT 2022 x86_64 GNU/Linux
Tags:
Steps To Reproduce:	Follow the directions here to build and then run "make check" https://linuxfromscratch.org/blfs/view/svn/postlfs/tcsh.html
Additional Information:
Attached Files:	testsuite.log (109,249 bytes) 2023-06-20 15:42 https://bugs.astron.com/file_download.php?file_id=347&type=bug

Notes
(0003956) cmeier    2023-06-20 15:42
(0003975) lukem    2023-09-11 10:37	Are you running the build and testsuite as root (uid 0)? If so, I don't think that's supported (nor good practice to build as root, in my opinion). I quickly reviewed your testsuite.log, searching for "FAILED", and scrolling back for details. Various test groups (such as test group 14) fail with a diff that expected lines starting with ">" and your lines start with "#". I think other tests rely upon not being able to read a file with mode 000, and those are working on your system too.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
468	[file] General	feature	N/A	2023-07-30 23:54	2023-08-05 14:46
Reporter:	quasar	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	HEAD
		Target Version:
Summary:	Add magic for NRRD imaging data format
Description:	NRRD (Nearly Raw Raster Data, https://teem.sourceforge.net/nrrd/format.html) is an imaging format used in medicine and other domains. Attached is a magic file to recognize NRRD files, as well as a sample NRRD file. More samples can be found at https://teem.sourceforge.net/nrrd/files/index.html
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	example.nrrd (16,456 bytes) 2023-07-30 23:54 https://bugs.astron.com/file_download.php?file_id=356&type=bug nrrd.magic (517 bytes) 2023-07-30 23:54 https://bugs.astron.com/file_download.php?file_id=355&type=bug

Notes
(0003973) christos    2023-08-05 14:46	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
469	[file] General	major	always	2023-08-03 14:31	2023-08-05 14:40
Reporter:	joveler	Platform:	x86, x64, arm64
Assigned To:	christos	OS:	Windows 10
Priority:	normal	OS Version:	22H2
Status:	resolved	Product Version:	5.45
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	HEAD
		Target Version:
Summary:	dllexport keyword required for building Win32 DLL
Description:	[*] Main issue In Windows, compiled libmagic-1.dll exports too many/empty function symbols. - MSYS2 MinGW-w64: Exports 134 functions - llvm-mingw: Exports 0 functions libmagic does not define any visibility keywords in Win32 builds. As a solution, `file_public` macro must be defined as `__declspec(dllexport)` in Win32. After the patch, clang-compiled libmagic-1.dll contains an almost correct export function table. - llvm-mingw: Exports 20 functions [*] Symbol export visibility issue In POSIX GCC, symbol export visibility is controlled by `__attribute__ ((__visibility__(...)))` keyword. - `__attribute__ ((__visibility__("default")))`: Always export function symbol. - `__attribute__ ((__visibility__("hidden")))`: Must not export symbol. - No Keyword: Decided by compiler policy. In Win32 MSVC, symbol export visibility is more strict. - `__declspec(dllexport)`: Expose function symbol to export table (EAT) - No keyword: Always prevent symbol from being exposed to EAT In MSYS2 MinGW-w64 or llvm-mingw, they have a relaxed policy on the `No Keyword` case. It is because they try to replicate POSIX behavior to some degree. - Latest MSYS2 MinGW-w64 has been exposing every function, at least in `libmagic-1.dll`. - Latest llvm-mingw follows MSVC policy, hiding every function symbol.     - llvm-mingw had the same policy as MinGW-w64, but it seems to be changed in 2023. In Windows, all libmagic functions were built without any visibility keyword. Thus MinGW-w64 build is exposing symbols that should have been hidden, like `file_apprentice`. LLVM/Clang build is not exposing any symbols. [*] Solution `__attribute__ ((__visibility__("default")))` and `__declspec(dllexport)` keywords are equivalent. And many other cross-platform libraries are mapping these two. I tested `__declspec(dllexport)` keyword in the Win32 build, and got llvm-mingw working. However, MinGW-w64 still exposes all functions. It would need more investigation. In the meantime, the attached patch will solve the issue at least on LLVM/Clang. The patch uses `WIN32` macro to detect Windows environment because existing code uses it. It may be changed to other macros, such as `__MINGW32__`.
Tags:	EAT, export, MinGW, Win32
Steps To Reproduce:	[Reproduce Instructions for Windows] 1. Install MSYS2, and download llvm-mingw, and radare2 from its GitHub page. 2. Unpack file-5.45-Win32-reproduce.tar.xz 3. Run `libmagic-msys2.sh` in MSYS2 shell, for example:   $ ./libmagic-msys2.sh -t /c/Tools/llvm-mingw-20230614-ucrt-x86_64 -a x86_64 /c/Build/file-5.45 4. Check EAT of `build-x86_64\libmagic-1.dll`. It can be done with radare2:   > C:\radare2\bin\r2 build-x86_64\libmagic-1.dll   > [0xYYYYYYYY]> is~ 5. Apply `Win32_visibility_dllexport.diff` patch, and retry compiling.
Additional Information:	I have attached lists of exported functions on Linux/Win32 binaries. Look through `symbols_results.zip`.
Attached Files:	file-5.45-Win32-reproduce.tar.xz (112,236 bytes) 2023-08-03 14:31 https://bugs.astron.com/file_download.php?file_id=359&type=bug Win32_visibility_dllexport.diff (781 bytes) 2023-08-03 14:31 https://bugs.astron.com/file_download.php?file_id=358&type=bug symbols_results.zip (8,025 bytes) 2023-08-03 14:31 https://bugs.astron.com/file_download.php?file_id=357&type=bug

Notes
(0003972) christos    2023-08-05 14:40	Applied, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
470	[file] General	minor	always	2023-08-04 14:26	2023-08-05 14:35
Reporter:	gadelat	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.41
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	HEAD
		Target Version:
Summary:	text/xml detected instead of image/svg+xml
Description:	Following file <?xml version="1.0" encoding="utf-16"?> <!-- Generator: Adobe Illustrator 27.6.1, SVG Export Plug-In . SVG Version: 6.00 Build 0) --> <svg version="1.1" id="Livello_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"      viewBox="0 0 2553.6 940.6" style="enable-background:new 0 0 2553.6 940.6;" xml:space="preserve"> <style type="text/css">     .st0{fill:#0076BD;} </style> <g>     <path class="st0" d="M2372.4,727.1l-15.1-26.6h-12.6v26.6h-5.6V666h17c11,0,19.2,5.5,19.2,16.6c0,10.6-5.8,15.6-12.2,17.1l16,27.4         H2372.4 M2355.1,670.9h-10.5v24.8h10.7c8.3,0,14.1-4.3,14.1-13.1C2369.5,674.8,2362.9,670.9,2355.1,670.9"/>     <path class="st0" d="M2308.6,697.7c0,25,20.5,45.4,45.5,45.4c24.8,0,45.3-20.4,45.3-45.4c0-25-20.5-45.3-45.3-45.3         C2329.1,652.4,2308.6,672.7,2308.6,697.7 M2312.6,697.7c0-22.9,18.5-41.5,41.6-41.5c22.6,0,41.3,18.6,41.3,41.5         c0,22.9-18.7,41.5-41.3,41.5C2331.1,739.2,2312.6,720.6,2312.6,697.7"/>     <path class="st0" d="M255.7,469.2c0-188.4,153.3-342.1,342.4-342.1c102.7,0,195.2,46.5,258,118l-219.5,0c-27,0-56.9,18.7-71.1,33.3         c-14.1,14.7-152.8,153.2-170.8,170.2c-18,16.9-31.2,20.7-54.8,20.7L255.7,469.2 M406.1,567.2c23.6,0,36.8-2.7,54.8-19.7         c18-16.9,156-154.3,170.6-170.1c13.9-15,44.3-33.8,71.3-33.8h213.9c-9.7-24.3-22.4-47.4-37-68.5l-163.3-0.1         c-23.8,0-45.5,12.3-58.4,24.9c-13.4,12.9-155.3,154.4-168.9,168.6c0,0-24.3,31-72.3,31l-159.9,0c2.2,23.6,6.8,45.7,13.4,67.7         L406.1,567.2z M479.6,666.5c23.6,0,36.7-3.6,54.7-20.7c20.9-19.8,154.3-156,170.6-173.5c13.9-14.9,44.1-33.3,71.3-33.3l163,0         c-1.7-24-6.1-43.8-12.6-66.1l-136.3,0c-23.9,0-46.7,12.7-59.9,24.9c-15.3,14.1-154.3,154-168.4,167.9c0,0-23.3,31.1-71.3,31.1         l-210.5,0c10,24.8,23.1,48.1,38.5,69.7L479.6,666.5z M342.5,696.2c62.5,70,153.8,114.9,255.5,114.9         c187.9,0,340.5-155.2,342.2-342.1l-83.7-0.1c-23.9,0-47.5,11.9-59.9,24.9C784,506.8,642.9,652,629.5,665.1c0,0-25.3,31.1-73.3,31.1         L342.5,696.2z M1405.8,509.7c-12.7-21.1-28.7-53.5-101-71.9c-75.9-19.2-106.3-26.6-126.8-31.1c-20.2-4.5-53.1-15.3-53.1-59.1         c0-40.1,39.9-61.3,82-61.3c40.6,0,94.2,17.3,102.7,80.2h96.1V509.7z M1912.2,218.8h-162.1l-91.3,352.1l-91.2-352.1h-161.9V332         c-49.4-130.9-158.4-136.1-191.6-136.1c-141.6,0-192.5,88.6-192.5,153.8c0,104.7,86.6,136.8,110.2,142.8         c20.5,5.2,123.1,29.7,143.3,35.8c24.8,7.5,44.5,29,44.5,55.8c0,25.3-19.7,67.5-94.4,67.5c-74.5,0-110-40.7-116.1-89.7h-100         c0,0-3.9,180.9,222.2,180.9c96.6,0,147.5-40.4,174.2-83.1v64.2h101l-4.1-379.1l104.9,379.1h102.7l104.9-379.1l-3.9,379.1h101V630         c22.9,46.8,76.4,113.1,191.5,113.1c129.9,0,194.7-80.6,205.9-182h-97.1c-6.8,49.4-50.9,88.9-108.3,88.9         c-15.8,0-129.2-8.6-129.2-181.6c0-119.1,61.1-186.9,129-186.9c21.4,0,93,9,102.7,93.9h96.1c-7.5-121.7-107.3-179.9-198.8-179.9         c-107.8,0-167.7,56.4-191.8,102.6V218.8z"/> </g> </svg> returns text/xml
Tags:
Steps To Reproduce:	❯ file --mime-type Logo_SMC.svg Logo_SMC.svg: text/xml
Additional Information:
Attached Files:	Logo_SMC.svg (5,564 bytes) 2023-08-04 14:26 https://bugs.astron.com/file_download.php?file_id=360&type=bug

Notes
(0003970) gadelat    2023-08-04 15:01	5.44 also affected
(0003971) christos    2023-08-05 14:35	The SVG magic was not matching text only checks and needed bumping its strength.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
457	[file] General	minor	have not tried	2023-06-12 11:53	2023-07-30 16:32
Reporter:	ulm	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.44
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	HEAD
		Target Version:
Summary:	application/vnd.hp-HPGL false positives
Description:	Forwarding Gentoo Linux bug https://bugs.gentoo.org/908401: sys-apps/file added detection for "Hewlett-Packard Graphics Language" in <https://github.com/file/file/commit/57df9984ca59a54a0ad2ac548bc155dabe07f03a>. This causes files in /etc/env.d that start with "PA" like "PATH" or "NP" as in "NPM_CONFIG_GLOBALCONFIG" to be detected as "Hewlett-Packard Graphics Language" files and not as "ASCII text". Configuration files or shell scripts starting with assignment of PATH or any other all-caps variable are very common, therefore the HPGL magic should do some additional plausibility checks in order to avoid false positives.
Tags:
Steps To Reproduce:	$ cat 95eselect-wine PATH="/etc/eselect/wine/bin" MANPATH="/etc/eselect/wine/share/man" XDG_DATA_DIRS="/etc/eselect/wine/share" $ file -i 95eselect-wine 95eselect-wine: application/vnd.hp-HPGL; charset=us-ascii $ file 95eselect-wine 95eselect-wine: Hewlett-Packard Graphics Language, starting with "PATH="/etc/eselect/wine/bin"" with "MANPATH="/"
Additional Information:
Attached Files:	95eselect-wine (107 bytes) 2023-06-12 11:53 https://bugs.astron.com/file_download.php?file_id=344&type=bug 50npm (39 bytes) 2023-06-16 20:15 https://bugs.astron.com/file_download.php?file_id=345&type=bug

Notes
(0003947) christos    2023-06-16 19:36	Applied patch from Joerg Jenderek. Does it help?
(0003953) ulm    2023-06-16 20:15	The patch doesn't fix the problem. The test file that I had attached is recognised as text/plain now: $ file -i 95eselect-wine 95eselect-wine: text/plain; charset=us-ascii $ file 95eselect-wine 95eselect-wine: ASCII text However, it still fails with another example in the /etc/env.d/ directory of a Gentoo Linux system: $ cat 50npm NPM_CONFIG_GLOBALCONFIG=/etc/npm/npmrc $ file -i 50npm 50npm: application/vnd.hp-HPGL; charset=us-ascii $ file 50npm 50npm: Hewlett-Packard Graphics Language, starting with "NPM_CONFIG_GLOBALCONFIG=/etc/npm/npmrc"
(0003968) thesamesam    2023-07-28 11:04	I can still reproduce that issue with the new file contents: ``` NPM_CONFIG_GLOBALCONFIG=/etc/npm/npmrc ``` with file-5.45.
(0003969) christos    2023-07-30 16:32	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
467	[file] General	major	have not tried	2023-07-23 06:38	2023-07-27 18:34
Reporter:	gamma	Platform:
Assigned To:	christos	OS:
Priority:	high	OS Version:
Status:	feedback	Product Version:
Product Build:		Resolution:	reopened
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	Improper MIME type for HWPX format
Description:	This previous patch https://bugs.astron.com/view.php?id=418 fixed the HWPX format detection, so HWPX is now recognized as "application/hwp+zip". But HWPX format is not registered with IANA, custom MIME type should be used with 'x-' prefix (https://en.wikipedia.org/wiki/Media_type#Unregistered_tree) so using 'application/hwp+zip' would be inappropriate. I'd suggest using the 'application/x-hwpx' instead. It follows the rules and has some consistency with the HWP format ('application/x-hwp'); I have a question that is not directly related to this topic: I found the following line in the HWP format `#!:mime application/haansofthwp`. Path 'file/magic/Magdir/ole2compounddocs', line 270, commit HEAD (baebbe86bc8d918103c4079839fc0b8585ef299b) What is this? Is it just a comment for additional information? I'm asking because application/haansofthwp is also used as MIME type for HWP format. Even it doesn't follow the rules. Thanks.
Tags:	hwp, hwpx, magic
Steps To Reproduce:
Additional Information:
Attached Files:	HWP2016.hwpx (14,377 bytes) 2023-07-23 06:38 https://bugs.astron.com/file_download.php?file_id=354&type=bug

Notes
(0003965) gamma    2023-07-23 06:49	Although mimetype has 'application/hwp+zip', it does not follow the protocols. I think the other solution might be to change to 'application/x-hwpx+zip'.
(0003966) christos    2023-07-27 17:56	added x-. The other (starts with #) is a comment.
(0003967) gamma    2023-07-27 18:34	I think adding only the 'x-' prefix might be a problem. Because when you use `isMimeType("application/x-hwp")' to check it, HWP5.0 formats and HWPX formats will be considered because they have the same type. So I think 'application/x-hwpx' or the 'application/x-hwpx+zip' would be better. I much prefer the 'application/x-hwpx' as the ODT format doesn't add the '+zip' suffix.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
466	[file] General	minor	always	2023-07-15 15:46	2023-07-18 16:16
Reporter:	Ricky Tigg	Platform:
Assigned To:	christos	OS:
Priority:	low	OS Version:
Status:	assigned	Product Version:	5.44
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Non-reported complete format names and document's number of pages
Description:	Hello. Note: PDF format documents created by LibreOffice. case 1 | Non-reported | mention "ODT documnent" and number of pages $ file -b 0.odt OpenDocument Text case 2 | Non-reported | PDF document's number of pages $ file -b 0.pdf PDF document, version 1.6 case 3 | Non-reported | PDF/A-3b-format document's complete format and number of pages $ file -b 0.pdf PDF document, version 1.7
Tags:
Steps To Reproduce:
Additional Information:	Number of pages reported while a PDF-format document is empty. $ file -b 0.pdf PDF document, version 1.6, 1 pages The expression "page(s)", which is suitable both for one or several pages, is worth adopting in the output.
Attached Files:

Notes
(0003958) christos    2023-07-17 15:58	Fixed the page(s) part, but the rest is hard to fix because file(1) depends on the pdf /Count attribute to print the number of pages; if that is not found then how can file(1) deduce the number of pages?
(0003964) Ricky Tigg    2023-07-18 16:16	The abilities of third-party tools for Linux to invariably and correctly report the complete name and number of pages of a PDF document are attested. I could reasonably assume that your tool was developed with such abilities. You feel it hard to do the job; that I dully understand.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
459	[file] General	minor	always	2023-06-20 08:30	2023-07-17 16:56
Reporter:	Albrecht	Platform:	x86_64
Assigned To:	christos	OS:	Debian
Priority:	normal	OS Version:	Bookworm
Status:	resolved	Product Version:	5.44
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	HTML Malware classified incorrectly
Description:	Please see the attached HTML Malware (!!) sample; extract it from the ZIP using the password InFeCtEd. Note that the HTML is somewhat broken, but apparently being processed as HTML by Windows applications. The original file v. 5.44 tar produces (correctly IMHO; local build) $ src/file -m magic/magic.mgc Warning-Malware.html Warning-Malware.html: HTML document, ISO-8859 text, with very long lines (47206), with CRLF line terminators $ src/file -m magic/magic.mgc --mime-type /Warning-Malware.html Warning-Malware.html: text/html Debian Bookworm comes with a slightly patched version, including inter alia this one: https://github.com/file/file/commit/a2756aa50fdf7d87ebb14002ffd7609373ea6839, and produces $ file Warning-Malware.html Warning-Malware.html: JavaScript source, ISO-8859 text, with very long lines (47206), with CRLF line terminators $ file --mime-type Warning-Malware.html Warning-Malware.html: application/javascript And the current master revision (c577678, again local build) from https://github.com/file/file seems to be broken $ src/file -m magic/magic.mgc Warning-Malware.html Warning-Malware.html: , 1st line ""
Tags:	bug, magic
Steps To Reproduce:	See above.
Additional Information:	It is somewhat debatable if in this particular case the classification as HTML (original v. 5.44) or JavaScript (commit a2756aa) should be preferred. However, as Windows apparently processes it as HTML, the former is IMHO better as it can be used to feed it into the proper malware analysis module. Note that the issue is not limited to this particular sample, I currently see a plethora of more or less similar malware files. I didn't test if the Win Script Host is even able to process this sample as JavaScript, though.
Attached Files:	Warning-Malware.zip (15,908 bytes) 2023-06-20 08:30 https://bugs.astron.com/file_download.php?file_id=346&type=bug

Notes
(0003963) christos    2023-07-17 16:56	Weird match. That was some debugging line probably. Now it says: [12:55pm] 1436>./file -m ../magic/Magdir/windows ~/Warning-Malware.html /Users/christos/Warning-Malware.html: ISO-8859 text, with very long lines (47206), with CRLF line terminators

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
461	[file] General	minor	always	2023-06-22 12:02	2023-07-17 16:49
Reporter:	bicknell	Platform:
Assigned To:	christos	OS:
Priority:	low	OS Version:
Status:	resolved	Product Version:	5.44
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	file does not recognize PaperPort MAX files.
Description:	File does not recognize files created from PaperPort scanners. PaperPort was a popular scanner in the late 1990's.
Tags:
Steps To Reproduce:	Run file against a PaperPort file.
Additional Information:	The web page at http://fileformats.archiveteam.org/wiki/PaperPort_(MAX) provides the following identification details: Paperport MAX files begin with three bytes in ascii "ViG" PaperPort 2 files begin with ViGAe or ViGBe PaperPort 3-4 files begin with ViGCj PaperPort 5-7 files begin with ViGEm PaperPort 8-12 files begin with ViGFk
Attached Files:

Notes
(0003962) christos    2023-07-17 16:49	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
462	[file] General	feature	N/A	2023-06-24 17:05	2023-07-17 16:42
Reporter:	dzwdz	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	support for the age, scrypt file encryption tools
Description:	https://age-encryption.org http://www.tarsnap.com/scrypt.html This is my first contribution, I hope I didn't mess anything up ^^
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	crypto (625 bytes) 2023-06-24 17:05 https://bugs.astron.com/file_download.php?file_id=348&type=bug

Notes
(0003961) christos    2023-07-17 16:42	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
463	[file] General	minor	always	2023-06-26 22:00	2023-07-17 16:08
Reporter:	oleg.andreyev	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.41
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	CSV is detected as ASCII text
Description:	CSV file is sometimes is detected as ASCII, while it's actually a CSV file.
Tags:
Steps To Reproduce:	Download attached two files: ``` ❯ file test.csv test.csv: ASCII text ``` ``` ❯ file test2.csv test2.csv: CSV text ```
Additional Information:
Attached Files:	test2.csv (17 bytes) 2023-06-26 22:00 https://bugs.astron.com/file_download.php?file_id=349&type=bug test.csv (13 bytes) 2023-06-26 22:00 https://bugs.astron.com/file_download.php?file_id=350&type=bug

Notes
(0003960) christos    2023-07-17 16:08	Fixed, thanks

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
464	[file] General	minor	always	2023-07-05 11:02	2023-07-17 16:01
Reporter:	jpalus	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.44
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	Perl module with package version not detected as Perl source
Description:	Sample Perl file: $ cat test.pm package foo 1.0; is not detected as Perl source: $ file test.pm test.pm: ASCII text That's because current pattern does not cover optional version following package name. Attached two patches: 1. Change perl detection regexes to use [:space:] class instead of fixed space 2. Add support for version following package name as per https://perldoc.perl.org/functions/package
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	0001-perl-use-space-class-instead-of-fixed-spaces.patch (1,079 bytes) 2023-07-05 11:02 https://bugs.astron.com/file_download.php?file_id=351&type=bug 0002-perl-detect-files-with-version-after-package-name.patch (1,418 bytes) 2023-07-05 11:02 https://bugs.astron.com/file_download.php?file_id=352&type=bug

Notes
(0003959) christos    2023-07-17 16:01	Applied thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
465	[file] General	crash	always	2023-07-06 12:09	2023-07-17 15:55
Reporter:	psrok1	Platform:	Alpine Linux (in Docker)
Assigned To:	christos	OS:	Alpine Linux
Priority:	normal	OS Version:	v3.18
Status:	resolved	Product Version:	5.44
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	SIGSEGV crash in cdf_ctime when musl is used (malicious Office document)
Description:	Hi! We found that libmagic crashes when certain Office documents are provided. When we use libmagic compiled with glibc, we get the following result: ``` bad-file-5c695a37c4eb17703e1d4b95b8c2366bcead07171d3ccb22c091a77bee9c9c81: Composite Document File V2 Document, Little Endian, Os: Windows, Version 5.0, Code page: 1252, Title: WinCC-Graphics-Document, Comments: Saved with Version: K6.0.2.0Saved with Version: K6.0.2.8Saved with Version: K6.0.3.0Saved with Version: K6.0.4.0Saved with Version: V6.2 incl. SP2Saved with Version: V6.2 incl. SP3 incl. HF12Saved with Version: V7.0 incl. SP3, Revision Number: 619, Total Editing Time: *Bad* 0x000000bb2bb31ea9, Last Saved Time/Date: Wed Jun 21 08:30:38 2023, Create Time/Date: Fri Feb 8 10:14:53 2002, Number of Pages: 1, Number of Words: 0, Number of Characters: 0, Name of Creating Application: Grafexe, 0x80000002: 0 ``` As you may notice, Total Editing Time is malformed and is shown as `*Bad* 0x000000bb2bb31ea9`. Unfortunately, when we use musl, we get segfault in asctime_r function called by cdf_ctime. After checking the root cause in gdb, we found that asctime_r (used by ctime_r) expects that result will fit in buffer having 26 bytes. When it exceeds the limit: glibc returns NULL and sets errno to EOVERFLOW (https://github.com/lattera/glibc/blob/master/time/asctime.c#L53), which is then handled by cdf_ctime code. Unfortunately, musl is more cautious and calls `a_crash()` which results in `HLT` trap causing SIGSEGV crash (https://git.musl-libc.org/cgit/musl/tree/src/time/asctime_r.c#n23). It looks like libmagic must validate time_t structure whether fields are in correct ranges before applying it to ctime_r. Bug also occurs in earlier versions of file (git blame shows that affected code wasn't changed for several years).
Tags:	bug, cdf
Steps To Reproduce:	We used the following Dockerfile: ``` FROM python:3.8-alpine AS build RUN apk add --no-cache build-base autoconf automake libtool gdb COPY file /app/file WORKDIR /app/file RUN autoreconf -i RUN ./configure RUN make COPY bad-file-5c695a37c4eb17703e1d4b95b8c2366bcead07171d3ccb22c091a77bee9c9c81 /app/ WORKDIR /app ```
Additional Information:	Test file: 5c695a37c4eb17703e1d4b95b8c2366bcead07171d3ccb22c091a77bee9c9c81 (MALICIOUS DOCUMENT, attached zip with password 'infected'.) Related issue: https://github.com/CERT-Polska/mwdb-core/issues/842
Attached Files:	bad-file-5c695a37c4eb17703e1d4b95b8c2366bcead07171d3ccb22c091a77bee9c9c81.zip (41,339 bytes) 2023-07-06 12:09 https://bugs.astron.com/file_download.php?file_id=353&type=bug

Notes
(0003957) christos    2023-07-17 15:55	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
458	[file] General	tweak	have not tried	2023-06-19 01:27	2023-06-19 13:45
Reporter:	xmdy61	Platform:	loongarch64
Assigned To:	christos	OS:
Priority:	low	OS Version:
Status:	feedback	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	the config.guess in file-5.44.tar.gz is too old
Description:	Architecture: loongarch64 LoongArch is a new architecture that is already supported by linux-6.1, gcc-12. My build type is loongarch64-unknown-linux-gnu,and the config.guess in file-5.44.tar.gz is too old,it cannot guess build type. I got the file-5.44.tar.gz from the following link: ftp://ftp.astron.com/pub/file/file-5.44.tar.gz
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003955) christos    2023-06-19 13:45	I will put a newer one for next version. In the meantime, rm -f config.guess; autoreconf -f -i

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
443	[file] General	minor	always	2023-04-26 20:43	2023-06-16 20:26
Reporter:	andrushka	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.43
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	Private PKCS8 SSH keys aren't recognized
Description:	Private PKCS8 SSH keys show up as ASCII text. Thanks!
Tags:
Steps To Reproduce:	ssh-keygen -m pkcs8 -f /tmp/debug_key.pass -qN 'passphrase' ssh-keygen -m pkcs8 -f /tmp/debug_key.nopass -qN '' file /tmp/debug_key.* # Shows: # /tmp/debug_key.nopass: ASCII text # /tmp/debug_key.nopass.pub: OpenSSH RSA public key # /tmp/debug_key.pass: ASCII text # /tmp/debug_key.pass.pub: OpenSSH RSA public key
Additional Information:	head -n 1 /tmp/debug_key.{,no}pass # Shows: # ==> /tmp/debug_key.pass <== # -----BEGIN ENCRYPTED PRIVATE KEY----- # # ==> /tmp/debug_key.nopass <== # -----BEGIN PRIVATE KEY----- Maybe relevant: https://www.rfc-editor.org/rfc/rfc5958
Attached Files:

Notes
(0003954) christos    2023-06-16 20:26	Added, thanks

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
453	[file] General	major	always	2023-05-22 11:56	2023-06-16 20:07
Reporter:	polluks	Platform:
Assigned To:	christos	OS:
Priority:	urgent	OS Version:
Status:	resolved	Product Version:	5.44
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	Make magic.mgc fails
Description:	[...] make[2]: Entering directory '/home/stefan/g/file/magic' ../src/file -C -m magic magic/dwarfs, 1: Warning: offset ``' invalid magic/images, 2565: Warning: offset `!mime image/vnd.radiance' invalid magic/svf, 5: Warning: no need to escape `:' file: could not find any valid magic files! make[2]: *** [Makefile:866: magic.mgc] Error 1 make[2]: Leaving directory '/home/stefan/g/file/magic' make[1]: *** [Makefile:463: all-recursive] Error 1 make[1]: Leaving directory '/home/stefan/g/file' make: *** [Makefile:372: all] Error 2
Tags:
Steps To Reproduce:	make clean all
Additional Information:
Attached Files:

Notes
(0003952) christos    2023-06-16 20:07	Should be fixed by now...

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
442	[file] General	feature	always	2023-04-26 14:49	2023-06-16 20:07
Reporter:	sprinter	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.44
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	DKIF / IVF formats not recognized
Description:	Does not recognize multimedia formats (recognized as data).
Tags:
Steps To Reproduce:
Additional Information:	https://gitlab.gnome.org/GNOME/gimp/-/issues/9356
Attached Files:	animation-woods.ivf (406,941 bytes) 2023-04-26 14:49 https://bugs.astron.com/file_download.php?file_id=332&type=bug

Notes
(0003944) polluks    2023-05-22 12:24	See https://chromium.googlesource.com/chromium/src/media/+/master/filters/ivf_parser.h
(0003951) christos    2023-06-16 20:07	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
454	[file] General	tweak	always	2023-05-24 15:14	2023-06-16 19:58
Reporter:	Albrecht	Platform:	x86_64
Assigned To:	christos	OS:	Debian
Priority:	normal	OS Version:	Bookworm
Status:	resolved	Product Version:	5.44
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	C source file classified as HTML
Description:	Some of my C source files (like the attached sample) are classified as /tmp/sample.c: HTML document, Unicode text, UTF-8 text if any comment contains Doxygen HTML-style links (see https://www.doxygen.nl/manual/autolink.html#linkurl). Removing the 5th line containing the link produces the expected result /tmp/sample.c: C source, Unicode text, UTF-8 text This is a little ugly as Doxygen is widely used for code documentation, and supports a variety of HTML commands to pimp up the output (see https://www.doxygen.nl/manual/htmlcmds.html). I didn't check if any other HTML tag command produces the same effect, though.
Tags:
Steps To Reproduce:	See above - just run file v. 5.44 or the latest Git version on the attached sample. Note that file 5.39 coming with Debian Bullseye correctly returns /tmp/sample.c: C source, UTF-8 Unicode text
Additional Information:
Attached Files:	sample.c (328 bytes) 2023-05-24 15:14 https://bugs.astron.com/file_download.php?file_id=341&type=bug

Notes
(0003950) christos    2023-06-16 19:58	Fixed, by bumping strength.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
455	[file] General	text	N/A	2023-06-02 02:13	2023-06-16 19:40
Reporter:	raf	Platform:	All
Assigned To:	christos	OS:	All
Priority:	low	OS Version:	All
Status:	resolved	Product Version:	5.44
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	Incomplete documentation for magic_getpath in libmagic.man
Description:	The libmagic manual entry only mentions magic_getpath() in relation to its return value. It doesn't include it in the list of available functions, and it doesn't explain what it does. Below, in the additional information section, is a patch to fix that. Technically, the existing statement that magic_getpath() returns NULL on error isn't true. It returns the system default path whenever there is an error, but it's probably harmless to leave that.
Tags:	patch
Steps To Reproduce:	Run "man libmagic" then search for "magic_getpath".
Additional Information:	diff --git a/doc/libmagic.man b/doc/libmagic.man index f006c828..ec5cca0c 100644 --- a/doc/libmagic.man +++ b/doc/libmagic.man @@ -84,6 +84,8 @@  .Fn magic_setparam "magic_t cookie" "int param" "const void *value"  .Ft int  .Fn magic_version "void" +.Ft const char * +.Fn magic_getpath "const char *magicfile" "int action"  .Sh DESCRIPTION  These functions  operate on the magic database file @@ -347,6 +349,18 @@ from  .In magic.h .  This can be used by client programs to verify that the version they compile  against is the same as the version that they run against. +.Pp +The +.Fn magic_getpath +command returns the colon separated list of magic database locations. If the +.Fa filename +is non-NULL, then it is returned. Otherwise, if the +.Dv MAGIC +environment variable is defined, then it is returned. +Otherwise, if +.Fa action +is 0 (meaning "file load"), then any user-specific magic database file is included. +Otherwise, only the system default magic database path is included.  .Sh RETURN VALUES  The function  .Fn magic_open
Attached Files:

Notes
(0003949) christos    2023-06-16 19:40	Committed, many thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
456	[file] General	minor	always	2023-06-05 16:52	2023-06-16 19:38
Reporter:	Albrecht	Platform:	x86_64
Assigned To:	christos	OS:	Debian
Priority:	normal	OS Version:	Bookworm
Status:	resolved	Product Version:	5.44
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	LRZip: wrong MIME type
Description:	For the attached LRZip sample, the human-readable message is correct: $ file sample.lrz sample.lrz: LRZIP compressed data - version 0.6 …but the MIME type is not – expected is “application/x-lrzip”: $ file --mime-type sample.lrz sample.lrz: application/octet-stream
Tags:	patch
Steps To Reproduce:	See above.
Additional Information:	I think the effect is caused by a bad order of statements in the file magic/Magdir/compress, at least the attached patch seems to fix the issue. No idea if it has any adverse effects, though.
Attached Files:	sample.lrz (81 bytes) 2023-06-05 16:52 https://bugs.astron.com/file_download.php?file_id=342&type=bug lrzip-mime.patch (527 bytes) 2023-06-05 16:52 https://bugs.astron.com/file_download.php?file_id=343&type=bug

Notes
(0003948) christos    2023-06-16 19:38	Committed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
452	[file] General	minor	always	2023-05-22 10:13	2023-06-01 16:01
Reporter:	lukem	Platform:
Assigned To:	christos	OS:	NetBSD
Priority:	normal	OS Version:	10.99.4
Status:	resolved	Product Version:	5.43
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	mdoc man pages misidentified as C source
Description:	I noticed that file 5.43 (as nbfile tool in NetBSD-current) misidentifies various mdoc man pages as C source. If I use file 5.41 on macOS 13.4 on the same source tree, it misidentifies a smaller subset.
Tags:
Steps To Reproduce:	cd src/lib/libc find . -name '*.[1-9]' | xargs path/to/file | grep -v 'troff or' | sort ./gen/ctype.3: C source, ASCII text ./gen/getdevmajor.3: C source, ASCII text ./gen/randomid.3: C source, ASCII text ./locale/nl_langinfo.3: C source, ASCII text ./net/getifaddrs.3: C source, ASCII text ./sys/dup.2: C source, ASCII text ./sys/mremap.2: C source, ASCII text ./sys/readlink.2: C source, ASCII text ./sys/select.2: C source, ASCII text ./sys/undelete.2: C source, ASCII text
Additional Information:	I discovered this whilst debugging NetBSD/src/share/man/man0 and observing different behaviour between the host file and the TOOLDIR nbfile, and realised that both were buggy, one was less buggy than the other.
Attached Files:

Notes
(0003942) polluks    2023-05-22 12:05	At least NetBSD 9.3 file-5.37 says $ file /usr/share/man/man3/ctype.3 /usr/share/man/man3/ctype.3: troff or preprocessor input, ASCII text
(0003943) lukem    2023-05-22 12:10	Yes, file 5.43 seems to detect more of that list as C instead of troff, but file 5.37 will still misidentify some of that list. Using file 5.37 (NetBSD 9.0, ftp.netbsd.org), checking /usr/share/man there's a bunch of mismatches including those I listed from libc. ./man1/flex.1: C source, ASCII text ./man1/lex.1: C source, ASCII text ./man1/calendar.1: C source, ASCII text ./man1/ident.1: C source, ASCII text ./man1/makeinfo.1: HTML document, ASCII text ./man1/sqlite3.1: HTML document, ASCII text ./man2/dup2.2: C source, ASCII text ./man2/dup.2: C source, ASCII text ./man2/dup3.2: C source, ASCII text ./man2/mremap.2: C source, ASCII text ...
(0003946) christos    2023-06-01 16:01	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
134	[tcsh] General	minor	always	2020-01-29 07:00	2023-06-01 15:31
Reporter:	Kazuo Kuroi	Platform:
Assigned To:	christos	OS:
Priority:	low	OS Version:
Status:	assigned	Product Version:	6.22.02
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	[tcsh 6.22.02] testsuite: 132 175 189 failed (IRIX 6.5.22/MIPSPro)
Description:	I am reporting some testsuite issues for IRIX 6.5.22 using the MIPSPro compiler 7.4.4m on IRIX 6.5.22 (later versions are nearly identical for these cases, for the record) configure command: % ./configure --disable-nls CC=c99 Version info: % c99 --version c99 ERROR: -- not allowed in non XPG4 environment c99 ERROR parsing --version: unknown flag MIPSpro Compilers: Version 7.4.4m % uname -spR IRIX 6.5 6.5.22m mips
Tags:
Steps To Reproduce:	run configure command make make test
Additional Information:	The release otherwise appears to be fine. I am more than happy to help troubleshoot the issue and if needed launch cvd (IRIX debugger)
Attached Files:	testsuite.log (97,932 bytes) 2020-01-29 07:00 https://bugs.astron.com/file_download.php?file_id=100&type=bug

Notes
(0003378) christos    2020-02-18 20:22	Can you try compiling without the optimizer? Or using gcc?
(0003387) Kazuo Kuroi    2020-02-22 21:29	Removed optimize flag from CLFAGS, exact same results After reviewing this again, I think the issue is that IRIX doesn't have gettent as part of its command set. I didn't realize this as I had been using getent from glibc on IRIX as part of some experiments, and thus my reason for being perplexed. Checking other IRIX machines, the exact same thing happens, so I feel that the main issue is the lack of getent on IRIX. If these test cases could be refactored to not use getent, I'm sure they'd pass on IRIX. OK to close.
(0003945) lukem    2023-06-01 15:31	Kazuo: is there an equivalent to getent(1) on IRIX that we can use instead? (It's been over 25 years since I last used an IRIX system). If not, we can instead modify the testsuite to skip those test groups if getent isn't available.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
437	[file] General	minor	always	2023-03-28 08:49	2023-05-22 05:38
Reporter:	laz	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:	5.44
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Match strength not accounted in custom magic definition
Description:	One can enrich the default magic database (in my case, "/usr/share/misc/magic.mgc") by adding a custom .mgc file in their home directory. Matches from this custom file however will always take precedence over the default definitions, regardless of the `strength` across all matches.
Tags:	magic
Steps To Reproduce:	# custom_magic 0 search/1024 ABC ABC file !:mime application/abc !:strength - 10 # default_magic 0 search/1024 ABCD ABCD file !:mime application/abcd !:strength + 50 # file -C -m default_magic && cp default_magic.mgc /usr/local/share/misc/magic.mgc # file -C -m custom_magic && cp custom_magic.mgc ~/.magic.mgc # file --list -m /usr/local/share/misc/magic.mgc Set 0: Binary patterns: Text patterns: Strength = 88@1: ABCD file [application/abcd] Set 1: Binary patterns: Text patterns: # file --list -m ~/.magic.mgc Set 0: Binary patterns: Text patterns: Strength = 29@1: ABC file [application/abc] Set 1: Binary patterns: Text patterns: # echo "ABCD" > abcd.txt && file abcd.txt -k abcd.txt: ABC file\012- ABCD file, ASCII text The order of the returned MIME types should have been reversed - `ABCD file\012- ABC file`
Additional Information:
Attached Files:

Notes
(0003939) christos    2023-05-21 17:28	The magic strengths of patterns are implemented by sorting magic entries within a set (a file) and then matching them in sequence. This is why you see that effect once you split the magic entries across multiple files. Fixing this would be very expensive at runtime (would require merging the entries for multiple files and then re-sorting. Not impossible, but is it really worth it?
(0003941) laz    2023-05-22 05:38	Hey christos I'm not aware of the implementation of the magic entries sorting, so feel free to close this one if you think it's going to be more of a headache than actually beneficial.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
435	[file] General	minor	always	2023-03-22 21:47	2023-05-22 01:44
Reporter:	haowenl	Platform:
Assigned To:	christos	OS:	Windows
Priority:	normal	OS Version:
Status:	assigned	Product Version:	5.44
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	file_magic: stat fails with errno EOVERFLOW on Windows for large files
Description:	On Windows, stat by default calls _stat64i32, which uses 32bit file length types. This causes stat to fail with EOVERFLOW for large files. This can be fixed by either using _stat64 for all files on Windows, or catch the EOVERFLOW errno and retry with _stat64.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003936) christos    2023-05-21 17:15	does adding: #ifdef _WIN64 #define stat _stat64 #endif in file.h fix it?
(0003940) haowenl    2023-05-22 01:44	Yes, that seems sufficient. Unfortunately tho, I do not currently have access to a Windows machine and cannot test it.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
445	[file] General	minor	always	2023-04-28 16:00	2023-05-21 17:24
Reporter:	milahu	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	feedback	Product Version:	5.44
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	file/libmagic fails to detect cp1252 encoding
Description:	actual result is the encoding "unknown-8bit" $ printf "what\x92s up?\n" | file -i - /dev/stdin: text/plain; charset=unknown-8bit expected result is cp1252: $ printf "what\x92s up?\n" | chardetect <stdin>: Windows-1252 with confidence 0.73 $ printf "what\x92s up?\n" | iconv -f cp1252 -t utf8 what’s up?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003938) christos    2023-05-21 17:24	Fixing it would require either implementing more heuristics to improve charset detection, or using a 3rd party library that already does this well. Both of these are fairly large projects to implement.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
451	[file] General	feature	N/A	2023-05-21 16:06	2023-05-21 17:19
Reporter:	mhx	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	Improved magic file for DwarFS file system images
Description:	Author of DwarFS here, following up on issue 449 (which was resolved while I was writing an update). I've been working on a magic file independently of @srjs when the issue was raised on the github issue tracker. I'm posting my magic file as well, as it uses stricter checks that prevent accidental matches, supports DwarFS images with headers, and outputs the block compression algorithm used. One thing that I don't know how to solve is that files with headers (which are typically shell scripts) will be identified either as shell scripts or as DwarFS images, depending on the order in which the magic file rules are read. I don't know what approach the file utility typically takes in case of such "hybrid" files.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	dwarfs.magic (1,659 bytes) 2023-05-21 16:06 https://bugs.astron.com/file_download.php?file_id=338&type=bug magictest.dwarfs (839 bytes) 2023-05-21 16:06 https://bugs.astron.com/file_download.php?file_id=339&type=bug magictest-header.dwarfs (951 bytes) 2023-05-21 16:06 https://bugs.astron.com/file_download.php?file_id=340&type=bug

Notes
(0003937) christos    2023-05-21 17:19	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
438	[file] General	minor	always	2023-04-03 12:00	2023-05-21 17:13
Reporter:	Touchstone64	Platform:	M1 Macbook Pro
Assigned To:	christos	OS:	MacOS
Priority:	normal	OS Version:	13.3 (22E252)
Status:	resolved	Product Version:	5.44
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	Some Apple QuickTime videos not recognised by file 5.44
Description:	Using the MacOS Image Capture utility, specifically Image Capture Version 8.0 (1106), importing 'live' photos and regular movies from an iPhone 14 Pro using iOS 16 results in QuickTime .MOV files. About 75% of these videos are recognised as 'video/quicktime' when using 'file --mime-type video.mov'. These videos contain atoms 'ftyp', 'wide', 'mdat' and 'moov' in that order. However, about 25% of the video files don't have the 'ftyp' atom, they just have 'wide', 'mdat' and 'moov', in that order. In these cases 'file --mime-type video.mov' identifies the video files as 'application/octet-stream'. Using exiftool, it can be seen that the 'MIME type' tag in these files is indeed 'video/quicktime'. .MOV files from earlier versions of iOS don't seem to have this issue, presumably a change in iOS is responsible for the different .MOV file content.
Tags:	QuickTime
Steps To Reproduce:	Use Image Capture to import a few dozen 'live' photos and videos from an iPhone running iOS 16. Use the command 'file --mime-type *.MOV' in the directory where the files are stored and observe the output on the command-line. (Unfortunately all my .MOV files with this content are larger than 2,048KiB so I can't upload one to demonstrate.)
Additional Information:	There is already a test for the 'wide' atom in source file ./magic/Magdir/animation 1.87, at line 21. Uncommenting lines 21 and 22 in that file, and using file's -m command-line option to use the modified magic file(s), file recognises the video files as 'video/quicktime'.
Attached Files:

Notes
(0003935) christos    2023-05-21 17:13	Uncommented, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
436	[file] General	minor	always	2023-03-23 15:17	2023-05-21 17:10
Reporter:	fstanchina	Platform:
Assigned To:	christos	OS:
Priority:	low	OS Version:
Status:	resolved	Product Version:	5.44
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	"file" reports incorrect line ending for a file with CR on 65536th byte
Description:	I have a file that is reported as having "CRLF, CR line terminators": ``` $ file xxx/file.cpp xxx/file.cpp: C source, ISO-8859 text, with CRLF, CR line terminators ``` After numerous attempts at re-saving it with uniform line terminators, it still reported an inconsistency. Turns out that "file" reads at most 65536 bytes to check for encoding and such, and this particular file has a CR exactly on the 65536th byte. So "file" doesn't see the LF on the 65537th byte and reports an inconsistency. This is obviously not a big problem, but I believe it's worth fixing if possible.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003934) christos    2023-05-21 17:10	Dup of PR/444

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
450	[file] General	minor	always	2023-05-20 19:04	2023-05-21 17:08
Reporter:	Ambie	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.44
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	SIMH emulated tape files (".tap") mis-identified as ATARI Degas
Description:	Emulated tape files for SIMH emulated tape drives are mis-identified as ATARI Degas Elite bitmap 640 x 400 x 2, color palette 0000 d08f 0000 0700 5dc1 ... SIMH is a well-known computer hardware emulator. (it will be the 0000001 result of a Google search for SIMH). Computers that have tape drives usually have simulated/emulated support on SIMH. There is a file format which (probably) will never change because a change in the format would cause widespread breakage to software which is distributed as SIMH tape files. Numerous SIMH tape files are distributed in the Internet Archive, The Unix Historical Society, SourceForge, GitHub, etc. References: https://github.com/simh/simtools
Tags:	bug, magic
Steps To Reproduce:	Install file. I tested this on Arch Linux 2023-05-20 and Ubuntu 23.04. Download a SIMH *.tap file. Example: https://www.tuhs.org/Archive/Distributions/UCB/4.1BSD-19810901-reconstructed/tape1.tap.xz $ unxz tape1.tap.xz $ file tape1.tap tape1.tap: Atari DEGAS Elite bitmap 640 x 400 x 2, color palette 0000 d08f 0000 0700 5dc1 ...
Additional Information:	Thanks for everything you do!
Attached Files:

Notes
(0003933) christos    2023-05-21 17:08	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
447	[file] General	minor	always	2023-05-11 17:24	2023-05-21 16:10
Reporter:	Albrecht	Platform:	x86_64
Assigned To:	christos	OS:	Debian
Priority:	normal	OS Version:	Bookworm
Status:	resolved	Product Version:	5.44
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	MIME type output: missing separator between matches from multiple magic files
Description:	In order to detect some broken or exotic file formats, I use a custom magic file in addition to the standard one coming with the Debian package. E.g. consider the following simple rule for broken (typically Malware) RTF files (which Word does open, btw.): 0 string {\\rt Rich Text Format (invalid header) !:mime text/rtf On Debian Bullseye (file v. 5.39) this used to work perfectly for detecting the MIME type, e.g. with the simple files in the attached ZIP: file --mime-type -k -m ./magext.mgc:/usr/share/misc/magic Test.rtf Test.rtf: text/rtf\012- file --mime-type -k -m ./magext.mgc:/usr/share/misc/magic broken.rtf broken.rtf: text/rtf\012- On Debian Bookworm (file v. 5.44) the output is file --mime-type -k -m ./magext.mgc:/usr/share/misc/magic Test.rtf Test.rtf: text/rtftext/rtf file --mime-type -k -m ./magext.mgc:/usr/share/misc/magic broken.rtf broken.rtf: text/rtf which looks as if the usual separator (“\012- ”) between multiple MIME types coming from different magic files is missing. For any input producing multiple MIME types from the same magic file the output is separated correctly.
Tags:
Steps To Reproduce:	* unpack the attached ZIP file * cd file_issue * if necessary, edit the script variable MAGIC to point to the standard magic file (the value in the script is the Debian file location) * ./runtest.sh Note: the archive contains the results of running the script on Bullseye/5.39 and Bookworm/5.44, respectively.
Additional Information:	For the RTF example above, it would be possible to fix the issue by adding a check like “not followed by the char f”. However, I noticed some more complex cases where e.g. the standard magic patterns classify the input as text/plain, whereas my rules actually detect a message/rfc822. Similar to the RTF example above, the output is “message/rfc822text/plain”, so this looks like a more general issue to me.
Attached Files:	file_issue.zip (2,590 bytes) 2023-05-11 17:24 https://bugs.astron.com/file_download.php?file_id=335&type=bug

Notes
(0003932) christos    2023-05-21 16:10	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
439	[file] General	minor	always	2023-04-07 21:43	2023-05-21 16:03
Reporter:	dajhorn	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.44
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	Add magic for SmartVersion binary patch files
Description:	This patch recognizes SVF files, which do the same thing as VCDIFF files.
Tags:	magic
Steps To Reproduce:
Additional Information:
Attached Files:	0001-Add-magic-for-SmartVersion-binary-patch-files.patch (1,082 bytes) 2023-04-07 21:43 https://bugs.astron.com/file_download.php?file_id=331&type=bug

Notes
(0003931) christos    2023-05-21 16:03	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
440	[file] General	minor	always	2023-04-11 11:55	2023-05-21 16:00
Reporter:	truff	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.41
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	Bug when using -z with an lzrip compressed file
Description:	file is not using the right options to call lrzip when using -z
Tags:
Steps To Reproduce:	$ file -z hello.lrz hello.lrz: ERROR:[lrzip: Option requires an argument -- 'o'] (LRZIP compressed data - version 0.6)
Additional Information:	from compress.c: #define lrzip_flags "-do" $ lrzip -h 2>&1 | grep -- -o,         -o, --outfile filename specify the output file name and/or path -o option is not what you are looking for here and there is no obvious option to have lrzip read content from stdin, it refuses to use /dev/stdin or - so the fix won't be trivial
Attached Files:

Notes
(0003930) christos    2023-05-21 16:00	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
441	[file] General	minor	always	2023-04-17 10:37	2023-05-21 15:51
Reporter:	fabianthdev	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.44
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	Radiance File MIME-Types Commented Out
Description:	When checking the file type of an `.hdr` Radiance file, the correct format is reported by `file`: ``` $ file radiance_file.hdr radiance_file.hdr: Radiance HDR image data ``` However, when querying for the MIME type, the correct value of `image/vnd.radiance` is not returned, instead the following MIME type is determined: ``` $ file --mime radiance_file.hdr radiance_file.hdr: application/octet-stream; charset=binary ``` Looking at `magic/Magdir/images`, it appears that the correct MIME type is defined for radiance files, however it seems to be commented out and is thus not returned. I would suggest the following patch to return the correct MIME type for Radiance files: ``` diff --git a/magic/Magdir/images b/magic/Magdir/images index 19e362ae..be10993a 100644 --- a/magic/Magdir/images +++ b/magic/Magdir/images @@ -2549,7 +2549,7 @@  # URL: http://local.wasp.uwa.edu.au/~pbourke/dataformats/pic/  # Radiance HDR; usually has .pic or .hdr extension.  0 string #?RADIANCE\n Radiance HDR image data -#!mime image/vnd.radiance +!:mime image/vnd.radiance    # From: Adam Buchbinder <adam.buchbinder@gmail.com>  # URL: https://www.mpi-inf.mpg.de/resources/pfstools/pfs_format_spec.pdf ``` If the MIME type definition has been commented out deliberately, please explain why.
Tags:
Steps To Reproduce:	Check the file type of a Radiance HDR file with the `file` command: ``` $ file --mime radiance_file.hdr ``` Result: `radiance_file.hdr: application/octet-stream; charset=binary` Expected result: `radiance_file.hdr: image/vnd.radiance; charset=binary`
Additional Information:
Attached Files:

Notes
(0003929) christos    2023-05-21 15:51	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
446	[file] General	minor	always	2023-05-02 20:01	2023-05-21 15:49
Reporter:	mike	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.41
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	PDF appendix allows header in first 1024 bytes; Magic looks in 256
Description:	TL;DR, I think this line needs to be changed to 1024, not 256: https://github.com/file/file/blob/FILE5_39/magic/Magdir/pdf#L39 ---- Long version.... The Seventh Circuit of Appeals in the United States has started publishing documents that do not comply with the PDF specification, but which do comply with the PDF Compatibility and Implementation notes from Appendix H of the specification. See attached for an example, or this link should work: http://media.ca7.uscourts.gov/cgi-bin/OpinionsWeb/processWebInputExternal.pl?Submit=Display&Path=Y2023/D04-27/C:22-2500:J:Brennan:aut:T:fnOp:N:3036932:S:0 The PDF specification says on page 92 that: > The first line of a PDF file is a header identifying the version of the PDF [...] For a file conforming to PDF 1.7, the header should be: > > `%PDF=1.7 (See: https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/pdfreference1.7old.pdf#page=92) Easy enough. But Appendix H of the same spec says: > Acrobat viewers require only that the header appear somewhere within the first 1024 bytes of the file. (See: https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/pdfreference1.7old.pdf#page=1102) A few years ago, this issue came up: https://bugs.astron.com/view.php?id=104 If I'm understanding correctly, a fix was put in place to look in the first 256 bytes of the file, here: https://github.com/file/file/blob/FILE5_39/magic/Magdir/pdf#L39 I think we just need to adjust this to look in the first 1024 bytes instead, and it should fix this and other issues.
Tags:
Steps To Reproduce:	1. Download the file 2. Run `file the-file.pdf` 3. Note that it's detected as `data`. 4. Do `head the-file.pdf` 5. Note that `%PDF-` is there, but that there's text before it. 6. Study the spec and appendix H 7. Note that this file opens properly in Adobe Reader, and other PDF readers. 8. Note that file doesn't follow the implementation (aka the defacto specification)
Additional Information:
Attached Files:	document.pdf (337,981 bytes) 2023-05-02 20:01 https://bugs.astron.com/file_download.php?file_id=334&type=bug

Notes
(0003928) christos    2023-05-21 15:49	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
444	[file] General	minor	always	2023-04-28 14:11	2023-05-21 15:43
Reporter:	beijingjazzpanda	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.44
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	different result when file length is bigger than 65537 bytes
Description:	for example, 2 text files, one's length is less than 65537 bytes, another is bigger than 65537 bytes. execute `file` on both files returned different information of EOL (End Of Line).
Tags:	file size
Steps To Reproduce:	unzip the attachment, execute the `test-script` bash script. The result will be like ``` $ ./test-script bigger_than_65537.txt: ASCII text, with CRLF, CR line terminators smaller_than_65537.txt: ASCII text, with CRLF line terminators ```
Additional Information:	The issue is similar with 0000071. [https://bugs.astron.com/view.php?id=71](https://bugs.astron.com/view.php?id=71)
Attached Files:	65537-file-length-issue.zip (1,252 bytes) 2023-04-28 14:11 https://bugs.astron.com/file_download.php?file_id=333&type=bug

Notes
(0003927) christos    2023-05-21 15:43	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
449	[file] General	feature	N/A	2023-05-20 08:41	2023-05-21 15:25
Reporter:	srjs	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	Add magic for the DWARFS compressed file system format
Description:	DwarFS ( https://github.com/mhx/dwarfs ) is a high compression read-only file system much like SquashFS or EROFS unrecognized by the file utility. Attached is a magic file to recognize DwarFS archives. The file format may be found at: https://github.com/mhx/dwarfs/blob/main/doc/dwarfs-format.md Also attached is a test file. Further test files may be found under the test folder of the project repo: https://github.com/mhx/dwarfs/tree/main/test
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	dwarfs.magic (242 bytes) 2023-05-20 08:41 https://bugs.astron.com/file_download.php?file_id=336&type=bug example.dwarfs (4,070 bytes) 2023-05-20 08:41 https://bugs.astron.com/file_download.php?file_id=337&type=bug

Notes
(0003926) christos    2023-05-21 15:25	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
448	[file] General	minor	always	2023-05-13 10:32	2023-05-18 13:29
Reporter:	Albrecht	Platform:	x86_64
Assigned To:	christos	OS:	Debian
Priority:	normal	OS Version:	Bookworm
Status:	resolved	Product Version:	5.44
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	invalid MIME type for broken input
Description:	Running file v. 5.44 for detecting the MIME type of the broken executable file as of issue 211 (https://bugs.astron.com/file_download.php?file_id=187&type=bug) returns $ file --mime-type -b ./file-error-sample application/x-executable, can't read section at -1 Note that the returned value is not a valid MIME type according to RFC 6838, Sect. 4.2. Whilst it would not be complicated to remove the broken extra output (starting at the “,”), this unnecessarily complicates any software parsing the output of file. Thus, the extra informational message should be present only when file shall produce human-readable output. When running file with the option --mime-type, the output should always comply with RFC 6838.
Tags:
Steps To Reproduce:	see above
Additional Information:	-
Attached Files:

Notes
(0003925) christos    2023-05-18 13:29	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
427	[file] General	major	always	2023-02-18 00:37	2023-05-09 18:08
Reporter:	a1rind	Platform:
Assigned To:	christos	OS:
Priority:	high	OS Version:
Status:	resolved	Product Version:	5.44
Product Build:		Resolution:	reopened
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	docx file is determined as zip
Description:	Hi! There is an OOXML format docx file that is being determined as application/zip. Unfortunately I can not share the document yet but I have some debug info that hopefully can help. The `zipinfo` list following directories/files: ``` Zip file size: 36239 bytes, number of entries: 36 -rw---- 4.5 fat 399 b- stor 80-Jan-01 00:00 [trash]/0000.dat -rw---- 4.5 fat 739 b- defN 80-Jan-01 00:00 _rels/.rels -rw---- 4.5 fat 41347 b- defN 80-Jan-01 00:00 word/document.xml -rw---- 4.5 fat 1116 b- defN 80-Jan-01 00:00 docProps/app.xml -rw---- 4.5 fat 381 b- stor 80-Jan-01 00:00 [trash]/0002.dat -rw---- 4.5 fat 269 b- stor 80-Jan-01 00:00 [trash]/0003.dat -rw---- 4.5 fat 450 b- stor 80-Jan-01 00:00 [trash]/0001.dat -rw---- 4.5 fat 288 b- defN 80-Jan-01 00:00 word/_rels/header1.xml.rels -rw---- 4.5 fat 288 b- defN 80-Jan-01 00:00 word/_rels/header3.xml.rels -rw---- 4.5 fat 3225 b- defN 80-Jan-01 00:00 word/fontTable.xml -rw---- 4.5 fat 2864 b- defN 80-Jan-01 00:00 word/footer1.xml -rw---- 4.5 fat 3380 b- defN 80-Jan-01 00:00 word/header1.xml -rw---- 4.5 fat 9807 b- defN 80-Jan-01 00:00 word/header2.xml -rw---- 4.5 fat 3380 b- defN 80-Jan-01 00:00 word/header3.xml -rw---- 4.5 fat 680 b- defN 80-Jan-01 00:00 word/media/image1.wmf -rw---- 4.5 fat 38367 b- defN 80-Jan-01 00:00 word/numbering.xml -rw---- 4.5 fat 9410 b- defN 80-Jan-01 00:00 word/settings.xml -rw---- 4.5 fat 31843 b- defN 80-Jan-01 00:00 word/styles.xml -rw---- 4.5 fat 6992 b- defN 80-Jan-01 00:00 word/theme/theme1.xml -rw---- 4.5 fat 483 b- defN 80-Jan-01 00:00 word/webSettings.xml -rw---- 4.5 fat 1768 b- stor 80-Jan-01 00:00 [trash]/0005.dat -rw---- 4.5 fat 296 b- defS 80-Jan-01 00:00 customXml/_rels/item1.xml.rels -rw---- 4.5 fat 201 b- defS 80-Jan-01 00:00 customXml/itemProps2.xml -rw---- 4.5 fat 219 b- defS 80-Jan-01 00:00 customXml/item2.xml -rw---- 4.5 fat 201 b- defS 80-Jan-01 00:00 customXml/itemProps1.xml -rw---- 4.5 fat 296 b- defS 80-Jan-01 00:00 customXml/_rels/item2.xml.rels -rw---- 4.5 fat 443 b- stor 80-Jan-01 00:00 [trash]/0004.dat -rw---- 4.5 fat 2383 b- defN 80-Jan-01 00:00 word/_rels/document.xml.rels -rw---- 4.5 fat 236 b- stor 80-Jan-01 00:00 [trash]/0006.dat -rw---- 4.5 fat 201 b- defS 80-Jan-01 00:00 customXml/itemProps3.xml -rw---- 4.5 fat 296 b- defS 80-Jan-01 00:00 customXml/_rels/item3.xml.rels -rw---- 4.5 fat 775 b- defN 80-Jan-01 00:00 docProps/core.xml -rw---- 4.5 fat 563 b- defN 80-Jan-01 00:00 docProps/custom.xml -rw---- 4.5 fat 2530 b- defN 80-Jan-01 00:00 [Content_Types].xml -rw---- 4.5 fat 11932 b- defS 80-Jan-01 00:00 customXml/item1.xml -rw---- 4.5 fat 587 b- defS 80-Jan-01 00:00 customXml/item3.xml 36 files, 178635 bytes uncompressed, 31036 bytes compressed: 82.6% ``` The first file listed is coming from a [trash] directory e.g. [trash]/0000.dat and the regex at line 36 here (https://github.com/file/file/blob/master/magic/Magdir/msooxml#L36) isn't expecting such file. Furthermore according to OOXML specification there can exists a trash directory: > Trash items represent parts that have been discarded or are no longer in use. Trash items shall not conform to OPC part naming guidelines as defined in ECMA-376-2 and shall not be associated with a content type. All trash items shall follow the naming scheme: [trash]/HHHH.dat where H represents a hexadecimal digit. As I see and understood the msooxml magic rules expects a certain order for files in order to identify correct content type based on magic bytes at certain memory locations. The presence of trash items is causing it to fail. Any tips and tricks to skip over trash items? Thanks!
Tags:	bug, magic
Steps To Reproduce:
Additional Information:
Attached Files:	unsupported-prepared.docx (182,798 bytes) 2023-03-13 11:33 https://bugs.astron.com/file_download.php?file_id=328&type=bug

Notes
(0003898) a1rind    2023-02-28 16:46	Hi! Any thoughts on this?
(0003903) christos    2023-03-05 19:52	Does this diff fix it? --- msooxml 16 Aug 2022 11:16:39 -0000 1.18 +++ msooxml 5 Mar 2023 19:51:25 -0000 @@ -33,7 +33,7 @@  # make sure the first file is correct  >0x1E use msooxml  >0x1E default x ->>0x1E regex \\[Content_Types\\]\\.xml|_rels/\\.rels|docProps|customXml +>>0x1E regex \\[trash\\]|\\[Content_Types\\]\\.xml|_rels/\\.rels|docProps|customXml  # skip to the second local file header  # since some documents include a 520-byte extra field following the file  # header, we need to scan for the next header
(0003909) a1rind    2023-03-09 10:43	Hi! Thanks for the response. The suggested change doesn't fix the problem. I think we need to skip trash files and have the logic after the regex works by reading bytes from the expected file header. As you notice those trash files are not in ordered, they could be anywhere not just at start or at bottom. Unfortunately I can not share the document yet but soon I will for the ease of debugging. Kind Regards!
(0003915) a1rind    2023-03-13 11:33	Hi! I've attached the problematic document. Had to remove some confidential information and manually zip it according to the order of the same files as before. Thanks!
(0003916) christos    2023-03-14 19:46	Fixed, thanks!
(0003918) a1rind    2023-03-15 12:49	Hi! Thanks a lot for looking into this. However the latest changes doesn't fix the issue I think. When I try the latest magic rules it still recognizes it as application/zip: ``` file -m msooxml unsupported-prepared.docx ``` Produces: ``` Zip archive data, at least v2.0 to extract, compression method=store ``` Also when I try to compile the rules with the latest changes I get the following error: ``` /usr/share/file/magic/mail.news, 84: Warning: Unparsable number `xu \b, dcrypt version %d' ```
(0003919) a1rind    2023-03-21 12:16	Hi! Any thoughts on the issue? or am I doing something wrong? Kind Regards!
(0003920) christos    2023-03-21 14:03	why is it picking up files from /usr/share/file/magic? Is there some environment setting? Also line 84 in the most recent version of file, does not match that string...
(0003921) a1rind    2023-04-04 10:22	Sorry for getting back late on this. Turned out the newer changes works only with the lates version. Tested with file-5.44 and works fine. But can not work with file-5.41, unable to test file-5.42 and file-5.43.
(0003924) christos    2023-05-09 18:08	Submitter verified it is fixed on the latest version.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
252	[file] General	minor	always	2021-03-31 07:40	2023-04-17 12:46
Reporter:	malat	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:	5.38
Product Build:		Resolution:	reopened
Projection:	none
ETA:	none	Fixed in Version:	5.41
		Target Version:
Summary:	mime-type: image/jpeg instead of image/jls
Description:	It would be nice to disambiguate 'image/jpeg' vs 'image/jls' mime type as seen in the example attached. $ file --mime-type filelogo.jls filelogo.jls: image/jpeg with: $ file --version file-5.38 magic file from /etc/magic:/usr/share/misc/magic For reference: * https://www.iana.org/assignments/media-types/image/jls Implementation used to generate this JPEG-LS file is at: * https://github.com/team-charls/charls
Tags:
Steps To Reproduce:	$ file --mime-type filelogo.jls filelogo.jls: image/jpeg
Additional Information:
Attached Files:	filelogo.jls (16,386 bytes) 2021-03-31 07:40 https://bugs.astron.com/file_download.php?file_id=214&type=bug

Notes
(0003591) christos    2021-04-19 18:58	Added, thanks!
(0003922) malat    2023-04-13 13:37	It seems the issue is back. At least on Debian: % file --mime-type filelogo.jls filelogo.jls: image/jpeg with: % file --version file-5.44 magic file from /etc/magic:/usr/share/misc/magic * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034353
(0003923) malat    2023-04-17 12:46	Upstream regression, bisect led to     commit 19d5ac6c83fb5d0d9a3868f0f6f2709b1f11882f     Author: Christos Zoulas <christos@zoulas.com>     Date: Sat Aug 28 12:30:52 2021 +0000         restore jpeg strength to beat msdos boot sector     Christoph

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
434	[file] General	minor	always	2023-03-15 14:19	2023-03-15 14:19
Reporter:	toni.reed	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:	5.44
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	DOS executable detection classifies files inside of OOXML documents as DOS block device drivers
Description:	file uses a heuristic to determine whether a file is a DOS executable, for example, a DOS block device driver. This heuristic seems too broad and imprecise. It regularly classifies files inside of OOXML documents created by Microsoft Word as DOS block device drivers. The email content filter amavis uses libmagick to determine the file type of email attachments and regularly rejects emails with OOXML documents when it is configured to reject executables for Microsoft operating systems and to unpack OOXML documents (default behaviour). Therefore, this heuristic is more than an exotic classification mistake. Multiple workarounds are documented on the Internet because the issues affects many users of amavis.
Tags:
Steps To Reproduce:	1. Create a file with the following contents: ff ff ff ff 00 00 00 00 For example: $ hexdump \[trash\]/0000.dat 0000000 ffff ffff 0000 0000 0000 0000 0000 0000 0000010 0000 0000 0000 0000 0000 0000 0000 0000 * 0000790 0000 0000 0000793 2. Let file determine the type of the file: $ file \[trash\]/0000.dat [trash]/0000.dat: DOS executable (block device driver)
Additional Information:	The relevant section in the file msdos seem to be # DOS device driver updated by Joerg Jenderek at May 2011,Mar 2017,Aug 2020 # URL: http://fileformats.archiveteam.org/wiki/DOS_device_driver # Reference: http://www.delorie.com/djgpp/doc/rbinter/it/46/16.html # https://amaus.net/static/S100/IBM/software/DOS/DOS%20techref/CHAPTER.009 0 ulequad&0x07a0ffffffff 0xffffffff and # DOS device driver attributes >4 uleshort&0x8000 0x0000 \bblock device driver However, the heuristic seems to broad that it might also classify other file as DOS executables and the entire heuristic seems to be affected. Classifying DOS executables also seems to be a hard problem as they don't seem to have an easily distinguishable magic number.
Attached Files:	0000.dat (1,939 bytes) 2023-03-15 14:19 https://bugs.astron.com/file_download.php?file_id=330&type=bug

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
433	[file] General	major	always	2023-03-14 12:58	2023-03-14 19:48
Reporter:	nix	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	Since f7a65db, ELF file magic is broken for all ELF files with a note section
Description:	The symptoms are simple: compiler@loom 7897 /usr/src/file/x86_64-silk/shai-build.silk% src/file src/.libs/libmagic.so.1.0.0 src/.libs/libmagic.so.1.0.0: ERROR: , dynamically linked Note section size too big (48 > 0) (Invalid argument)
Tags:
Steps To Reproduce:	(see above)
Additional Information:	Caused by missing initialization of recently added ms->elf_shsize_max. Patch attached.
Attached Files:	shsize-max.diff (442 bytes) 2023-03-14 12:58 https://bugs.astron.com/file_download.php?file_id=329&type=bug

Notes
(0003917) christos    2023-03-14 19:48	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
421	[file] General	minor	always	2023-02-04 19:48	2023-03-11 18:27
Reporter:	bbaovanc	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.44
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	Debian package with control file with zstd compression has extension truncated
Description:	Debian packages (.deb) that have the control archive compressed with zstd will be named `control.tar.zst`, but the last letter of that filename gets chopped off in the output from `file`.
Tags:
Steps To Reproduce:	1. Download attached deb 2. Run `file com.jaidan.testtool_1.0.0_all.deb` 3. Note that it says "with control.tar.zs"
Additional Information:	Looking at `magic/Magdir/archive:274`, it looks like it only reads a 14-character long filename for the control archive. That works for `control.tar.gz` and `control.tar.xz`, but `control.tar.zst` is 15 characters long.
Attached Files:	com.jaidan.testtool_1.0.0_all.deb (2,202 bytes) 2023-02-04 19:48 https://bugs.astron.com/file_download.php?file_id=326&type=bug

Notes
(0003914) christos    2023-03-11 18:27	Widened, thanks.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
423	[file] General	minor	always	2023-02-12 23:25	2023-03-11 18:12
Reporter:	jpferreira	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.44
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	Doesn't properly identify Mathematica notebooks MIME type
Description:	Trying to identify a Mathematica notebook MIME type using "file" will say "text/plain", even thought Mathematica has registered MIME types, which you can see in the section "Background & Context" on the following URL: https://reference.wolfram.com/language/ref/format/NB.html Also, the beginning of the file also includes some information about that, e.g.: (* Content-type: application/vnd.wolfram.mathematica *) (*** Wolfram Notebook File ***) (* http://www.wolfram.com/nb *) (* CreatedBy='Mathematica 12.1' *) (*CacheID: 234*) (* Internal cache information: NotebookFileLineBreakTest NotebookFileLineBreakTest NotebookDataPosition[ 158, 7] NotebookDataLength[ 405898, 6949] NotebookOptionsPosition[ 403928, 6910] NotebookOutlinePosition[ 404321, 6926] CellTagsIndexPosition[ 404278, 6923] WindowFrame->Normal*) (* Beginning of Notebook Content *) (...)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003913) christos    2023-03-11 18:12	Added, thanks

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
432	[file] General	minor	always	2023-03-08 22:55	2023-03-11 17:54
Reporter:	maarten	Platform:	Linux
Assigned To:	christos	OS:	Fedora
Priority:	normal	OS Version:	6.1.14-100.fc36.
Status:	resolved	Product Version:	5.41
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	file does not recognize precompiled files, generated by llvm
Description:	Precompiled headers, generated by llvm (clang), are not recognized by file. $ file pch.h.pch pch.h.pch: data
Tags:
Steps To Reproduce:	# Copy/paste these commands to your terminal. # They require clang to be available. # 1. Create a small header cat >pch.h <<EOF __attribute__((visibility("default"))) int myfunction(void); EOF # 2. Create a dummy source file cat >pch.c <<EOF EOF # 3. Build the precompiled header clang -Xclang -emit-pch -Xclang -include -Xclang pch.h -x c-header -o pch.h.pch -c pch.c # 4. Run file on the precompiled header file pch.h.pch
Additional Information:
Attached Files:

Notes
(0003912) christos    2023-03-11 17:54	Added, thanks

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
428	[file] General	tweak	always	2023-02-24 15:56	2023-03-11 17:48
Reporter:	lu3	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:	5.44
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	extended filesystem: ext2/3/4 (ext4 identified as ext2)
Description:	In short: file identifies ext4 file system as ext2. Long story: I have this ext4 file system that once was an ext2 file system. The kernel now only supports mounting it as ext4, since I added extra_isize (which is ext4-only). To create such a file system, use "mke2fs -t ext2", then use "tune2fs -O extra_isize" on the file system. The Linux kernel will then only mount it as ext4. (Like it will only mount an ext2 with added journal, e.g. tune2fs -O has_journal, as ext3 or ext4...) Suggestion: Change "ext2" to either "extended filesystem" (or "extended file system", but the man pages write "filesystem" without space), which includes the original ext, ext2, ext3 and ext4. OR change the text to "ext2/3/4". OR include additional logic to distinguish ext2, ext3 and ext4 more reliably. I did some testing and created ext2/ext3/ext4 file systems (as sparse files). The results are inconsistent. For example I created an ext4 file system, the default features are: "has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum". I then deactivated most, except extends and flex_bg everything I could bring back to ext2 standards, leaving "ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file uninit_bg". NOTE that this is now STILL an ext4 filesystem due to extends! file now identifies it as ext2...
Tags:	file system
Steps To Reproduce:	# dd if=/dev/zero of=sparse_file bs=1 count=0 seek=512M 0+0 records in 0+0 records out 0 bytes copied, 3.8972e-05 s, 0.0 kB/s # mke2fs -t ext2 sparse_file mke2fs 1.46.5 (30-Dec-2021) Discarding device blocks: done Creating filesystem with 131072 4k blocks and 32768 inodes Filesystem UUID: 60ab585c-0cc5-4e1c-b89d-98ee8eab6ef6 Superblock backups stored on blocks:         32768, 98304 Allocating group tables: done Writing inode tables: done Writing superblocks and filesystem accounting information: done # tune2fs -O extra_isize sparse_file tune2fs 1.46.5 (30-Dec-2021) # dumpe2fs -h sparse_file | grep features dumpe2fs 1.46.5 (30-Dec-2021) Filesystem features: ext_attr resize_inode dir_index filetype sparse_super large_file extra_isize # file sparse_file sparse_file: Linux rev 1.0 ext2 filesystem data, UUID=60ab585c-0cc5-4e1c-b89d-98ee8eab6ef6 (large files) # rm sparse_file # dd if=/dev/zero of=sparse_file bs=1 count=0 seek=512M 0+0 records in 0+0 records out 0 bytes copied, 4.1416e-05 s, 0.0 kB/s # mke2fs -t ext4 sparse_file mke2fs 1.46.5 (30-Dec-2021) Discarding device blocks: done Creating filesystem with 131072 4k blocks and 32768 inodes Filesystem UUID: bf3337cb-bdd0-489c-a161-3d77450c4341 Superblock backups stored on blocks:         32768, 98304 Allocating group tables: done Writing inode tables: done Creating journal (4096 blocks): done Writing superblocks and filesystem accounting information: done # dumpe2fs -h sparse_file | grep features dumpe2fs 1.46.5 (30-Dec-2021) Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum Journal features: (none) # tune2fs -O ^has_journal,^64bit,^huge_file,^dir_nlink,^extra_isize,^metadata_csum sparse_file tune2fs 1.46.5 (30-Dec-2021) Disabling checksums could take some time. Proceed anyway (or wait 5 seconds to proceed) ? (y,N) y Please run e2fsck -f on the filesystem. After running e2fsck, please run `resize2fs -s sparse_file' to disable 64-bit mode. # e2fsck -f sparse_file e2fsck 1.46.5 (30-Dec-2021) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Block bitmap differences: +(98304--98368) Fix<y>? yes to all Free blocks count wrong for group 0000001 (36799, counted=32703). Free blocks count wrong for group 0000002 (28672, counted=32768). sparse_file: ***** FILE SYSTEM WAS MODIFIED ***** sparse_file: 11/32768 files (0.0% non-contiguous), 2257/131072 blocks # resize2fs -s sparse_file resize2fs 1.46.5 (30-Dec-2021) Converting the filesystem to 32-bit. The filesystem on sparse_file is now 131072 (4k) blocks long. # dumpe2fs -h sparse_file | grep features dumpe2fs 1.46.5 (30-Dec-2021) Filesystem features: ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file uninit_bg # file sparse_file sparse_file: Linux rev 1.0 ext2 filesystem data, UUID=bf3337cb-bdd0-489c-a161-3d77450c4341 (extents) (large files) # rm sparse_file
Additional Information:	(My ext2+extra_isize=ext4 is on /dev/nvme0n1p5:) # dumpe2fs -h /dev/nvme0n1p5 | grep features dumpe2fs 1.46.5 (30-Dec-2021) Filesystem features: ext_attr resize_inode dir_index filetype sparse_super large_file extra_isize # mount -t ext2 /dev/nvme0n1p5 /boot mount: /boot: wrong fs type, bad option, bad superblock on /dev/nvme0n1p5, missing codepage or helper program, or other error.        dmesg(1) may have more information after failed mount system call. # mount -t ext3 /dev/nvme0n1p5 /boot mount: /boot: wrong fs type, bad option, bad superblock on /dev/nvme0n1p5, missing codepage or helper program, or other error.        dmesg(1) may have more information after failed mount system call. # dmesg -t | tail EXT4-fs (nvme0n1p5): couldn't mount as ext2 due to feature incompatibilities EXT4-fs (nvme0n1p5): couldn't mount as ext3 due to feature incompatibilities # mount -t ext4 /dev/nvme0n1p5 /boot # dmesg -t | tail EXT4-fs (nvme0n1p5): mounted filesystem 01234567-89ab-cdef-fecd-ba9876543210 without journal. Quota mode: disabled. ext4 filesystem being mounted at /boot supports timestamps until 2038 (0x7fffffff) # file -s /dev/nvme0n1p5 /dev/nvme0n1p5: Linux rev 1.0 ext2 filesystem data (mounted or unclean), UUID=01234567-89ab-cdef-fecd-ba9876543210, volume name "Linux boot" (large files)
Attached Files:

Notes
(0003905) christos    2023-03-05 19:56	The test for ext2 vs 3,4 is if it has a journal. I guess we should make it smarter. Do you know where the flags vs versions documentation lives?
(0003911) lu3    2023-03-11 17:48	If not from the Linux kernel sources themselves, I guess maybe the Ext4 (and Ext2/Ext3) Wiki can be informative: https://ext4.wiki.kernel.org/index.php/Main_Page Especially the https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout should describe what you need. The man page also lists which features correspond with which extended filesystem version: https://www.man7.org/linux/man-pages/man5/ext4.5.html I'm not sure what the real differences are, since the ext4 kernel driver can mount ext2/3/4 as well, hence my suggestion to simply call it all "extended filesystem". I guess a logic would simply have to check for the enabled features and decide whether it's an ext2, ext3 or ext4 based on them: ext2 = filetype | sparse_super | large_file | ext_attr ext3 = filetype | sparse_super | large_file | has_journal | ext_attr | dir_index | resize_inode ext4 = (all the rest, currently:) filetype | sparse_super | large_file | has_journal | ext_attr | dir_index | resize_inode | 64bit | dir_nlink | extent | extra_isize | flex_bg | huge_file | meta_bg | uninit_bg | mmp | bigalloc | quota | inline_data | sparse_super2 | metadata_csum | encrypt | metadata_csum_seed | project | ea_inode | large_dir | casefold | verity | stable_inodes This does, however, leave out the original extended filesystem ("ext1" if you will, or "ext").

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
424	[file] General	feature	N/A	2023-02-15 11:27	2023-03-05 20:16
Reporter:	polluks	Platform:	MacBookPro17,1
Assigned To:	christos	OS:	macOS
Priority:	normal	OS Version:	12.5
Status:	resolved	Product Version:	5.44
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	audio update
Description:	mod.get psyched: 4-channel Protracker module sound data Title: "get psyched" mod.lose: 4-channel Protracker module sound data Title: "lose" mod.metal heads: 4-channel Protracker module sound data Title: "metal heads" mod.metallic bop amiga: 4-channel Protracker module sound data Title: "metallic bop amiga" mod.robot attack: 4-channel Protracker module sound data Title: "robot attack" mod.rushin in: 4-channel Protracker module sound data Title: "rushin in" mod.soundfx: 4-channel Protracker module sound data Title: "soundfx" mod.win: 4-channel Protracker module sound data Title: "win" https://github.com/zeropolis79/PETSCIIRobots-SDL/tree/main/Music
Tags:
Steps To Reproduce:	diff --git a/magic/Magdir/audio b/magic/Magdir/audio index 7a0a192b..c7fa4b38 100644 --- a/magic/Magdir/audio +++ b/magic/Magdir/audio @@ -188,6 +188,7 @@  #audio/x-protracker-module  >0 string >\0 Title: "%s"  1080 string M!K! 4-channel Protracker module sound data +1080 string !PM! 4-channel Protracker module sound data  !:mime audio/x-mod  #audio/x-protracker-module  >0 string >\0 Title: "%s"
Additional Information:	Running test: ../tests/cmd1 TZ=UTC MAGIC=../magic/magic ./test -e ../tests/cmd1.testfile ../tests/cmd1.result ../tests/cmd1.testfile: 4-channel Protracker module sound data test: ERROR: result was (len 38) 4-channel Protracker module sound data expected (len 46) a /usr/bin/cmd1 script, ASCII text executable
System Description	Apple M1
Attached Files:

Notes
(0003895) polluks    2023-02-15 12:01	Magic fixed, check ok: diff --git a/magic/Magdir/audio b/magic/Magdir/audio index 7a0a192b..c7fa4b38 100644 --- a/magic/Magdir/audio +++ b/magic/Magdir/audio @@ -188,6 +188,7 @@  #audio/x-protracker-module  >0 string >\0 Title: "%s"  1080 string M!K! 4-channel Protracker module sound data +1080 string \!PM! 4-channel Protracker module sound data  !:mime audio/x-mod  #audio/x-protracker-module  >0 string >\0 Title: "%s"
(0003908) christos    2023-03-05 20:16	Added (the bang needed to be escaped that's why the test broke).

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
425	[file] General	minor	always	2023-02-15 12:04	2023-03-05 20:04
Reporter:	polluks	Platform:	MacBookPro17,1
Assigned To:	christos	OS:	macOS
Priority:	high	OS Version:	13.2
Status:	feedback	Product Version:	5.44
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	check fails
Description:	Running test: ../tests/hello-racket_rkt TZ=UTC MAGIC=../magic/magic ./test -e ../tests/hello-racket_rkt.testfile ../tests/hello-racket_rkt.result ../tests/hello-racket_rkt.testfile: Racket bytecode (version \002) test: ERROR: result was (len 30) Racket bytecode (version \002) expected (len 30) Racket bytecode (version 8.5)
Tags:
Steps To Reproduce:
Additional Information:
System Description	Apple M1
Attached Files:

Notes
(0003907) christos    2023-03-05 20:04	Interesting, I tried it on my M1 with 13.2.1 and I could not reproduce it...

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
426	[file] General	minor	always	2023-02-17 15:04	2023-03-05 20:01
Reporter:	claudiu	Platform:
Assigned To:	christos	OS:	Ubuntu
Priority:	normal	OS Version:	20.04
Status:	resolved	Product Version:	5.44
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	Error "lhs/off overflow 4294967295 0" is printed to console
Description:	When running "file" over files which are composed of only 0xff bytes (at least 6 bytes), I get the above error. For example: {code} $ ./file -m magic.mgc ff.bin lhs/off overflow 4294967295 0 ff.bin: ISO-8859 text, with no line terminators $ hexdump -C ff.bin 00000000 ff ff ff ff ff ff |......| 00000006 {code} The error seems to be generated from the do_ops function: {code} file_private int do_ops(struct magic *m, uint32_t *rv, intmax_t lhs, intmax_t off) {     intmax_t offset;     // On purpose not INTMAX_MAX     if (lhs >= UINT_MAX || lhs <= INT_MIN ||         off >= UINT_MAX || off <= INT_MIN) {         fprintf(stderr, "lhs/off overflow %jd %jd\n", lhs, off);         return 1;     } {code} , but my knowledge of libmagic is limited so I don't understand why this is a problem. Aside from the error itself, I'm wondering why such errors are printed to the console, since this is part of the libmagic functionality...but of course, this is a separate issue.
Tags:	bug
Steps To Reproduce:	1. Create a file with only 0xff bytes: {code} $ printf "\xff\xff\xff\xff\xff\xff" > ff.bin {code} 2. Run "file" on it: {code} $ ./file -m magic.mgc ff.bin lhs/off overflow 4294967295 0 ff.bin: ISO-8859 text, with no line terminators {code}
Additional Information:	I first encountered this in a file from an ISO archive: https://mirror.netsite.dk/centos/7.9.2009/isos/x86_64/CentOS-7-x86_64-DVD-2207-02.iso The file location within the ISO is: CentOS-7-x86_64-DVD-2207-02.iso --> Packages/ecj-4.5.2-3.el7.x86_64.rpm --> ecj-4.5.2-3.el7.src.cpio.xz --> ecj-4.5.2-3.el7.src.cpio --> ./usr/share/java/ecj.jar --> org/eclipse/jdt/internal/compiler/parser/unicode/part2.rsc
Attached Files:	softmagic.c.patch (3,506 bytes) 2023-02-23 08:39 https://bugs.astron.com/file_download.php?file_id=327&type=bug

Notes
(0003896) polluks    2023-02-20 13:32	workaround "2>/dev/null"
(0003897) claudiu    2023-02-23 08:39	I've attached a patch that only prints those messages to stderr if the MAGIC_DEBUG flag is set. This seems to be the rule in the libmagic code, aside from some special cases (e.g. if CDF_DEBUG is defined).
(0003906) christos    2023-03-05 20:01	Fixed to only print debugging with debug.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
429	[file] General	minor	always	2023-02-27 06:54	2023-03-05 19:52
Reporter:	xry111	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.44
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	Build failure with gcc 4.8
Description:	We have the following build failure with file 5.44 and gcc 4.8:   CC funcs.lo ../../src/funcs.c: In function 'check_regex': ../../src/funcs.c:665:2: error: 'for' loop initial declarations are only allowed in C99 mode   for (const char *p = pat; *p; p++) {   ^ ../../src/funcs.c:665:2: note: use option -std=c99 or -std=gnu99 to compile your code make[3]: *** [Makefile:571: funcs.lo] Error 1
Tags:	build
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003904) christos    2023-03-05 19:52	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
431	[file] General	minor	always	2023-03-04 20:50	2023-03-05 19:45
Reporter:	Barteks2x	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.44
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	ERROR: (null) when running with --mime-type on a specific byte sequence
Description:	I found this issue while trying to use the source code of "file" to make a "data recovery" tool for my own use that scans a disk for file signatures, and ran into this error. The shortest sequence of bytes (in hex) that reproduces this issue is: 0000 feff f9ff f6ff
Tags:
Steps To Reproduce:	printf "\x00\x00\xfe\xff\xf9\xff\xf6\xff" > test && file --mime-type test
Additional Information:	After debugging it and reading the code this behavior seems intentional, but previous bug reports about similar output seem to contradict that observation. It appears to fail in file_ascmagic, in file_ascmagic_with_encoding - it initially detects this as a UTF-32 file but then attempts to handle it as UTF-8. But overall outputting that error when this code fails to get any information about the text seems intentional.
Attached Files:

Notes
(0003902) christos    2023-03-05 19:45	fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
430	[file] General	tweak	always	2023-03-03 01:38	2023-03-05 19:02
Reporter:	lbrtchx	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	feedback	Product Version:	5.39
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	is there a way to get just the basic metadata about a file type without too much specifics about the particular file?
Description:	if you use:  file --brief --mime "$file"  you would get too little, practically unusable info.  file --brief "$file"  would give you what you need when it comes to pdf files (yes, the structure of pdf files depends on their version), but with images it gives you data relating to the specific file, such as:  org/wikipedia/en/Big_Bang_files/16px-He1523a.jpg|JPEG image data, baseline, precision 8, 16x18, components 3  org/wikipedia/en/East_Germany_files/20px-DDR_-_helfer_der_volkspolizei.jpg|JPEG image data, baseline, precision 8, 20x13, components 3  org/wikipedia/en/Country_code_top-level_domain_files/23px-Flag_of_Hong_Kong.png|PNG image data, 23 x 15, 8-bit colormap, non-interlaced  org/wikipedia/en/Country_code_top-level_domain_files/45px-Flag_of_Venezuela.png|PNG image data, 45 x 30, 8-bit colormap, non-interlaced  is there a way to go like:  file --brief --no-specifics "$file"  to just get:  JPEG image data, baseline, precision 8, components 3  PNG image data, 8-bit colormap, non-interlaced  If not I would propose it as a recommendation/RFE of sort.  You could always use some code to clean up the output from file, but it would be optimal is file had that option.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003901) christos    2023-03-05 19:02	So the size of the image is the only information that should be considered image-specific?

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
422	[file] General	feature	always	2023-02-07 06:13	2023-02-07 06:13
Reporter:	wzy	Platform:
Assigned To:		OS:
Priority:	low	OS Version:
Status:	new	Product Version:	5.44
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	shell completion
Description:	Can file has shell completions for bash/zsh/...?
Tags:	completion, shell
Steps To Reproduce:
Additional Information:	Some projects like [github-cli](https://github.com/cli/cli/blob/cf4b73ff958b272cf3c9c0cf9351459f76b793a0/pkg/cmd/completion/completion.go) maintained shell completions in their repository and some projects maintained shell completions in other repositories like bash-completion. (file has a bash completion in bash-completions although it is old.)
Attached Files:

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
419	[file] General	minor	always	2023-02-02 06:56	2023-02-04 13:23
Reporter:	davidjb	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.44
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	Add Cflags compile-time flags for pkg-config
Description:	Being able to use libmagic (magic.h) requires knowledge of where it its headers are located on the system. In my case, I'm compiling a project that depends on magic.h on a system where the path isn't set system wide (e.g. macOS, Homebrew). In other words by running `pkg-config --cflags` should return the location of the header files for this project such that it's usable. I've attached the patch that facilitates this for libmagic.pc.in. It would be greatly appreciated if you could incorporate this fix. Thanks very much for such a useful library!
Tags:
Steps To Reproduce:	1. ./configure && make && make install 2. Run pkg-config --cflags and observe no output
Additional Information:
Attached Files:	libmagic.pc.in-cflags.patch (273 bytes) 2023-02-02 06:56 https://bugs.astron.com/file_download.php?file_id=325&type=bug

Notes
(0003894) christos    2023-02-04 13:23	committed, thanks

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
420	[file] General	minor	have not tried	2023-02-03 20:35	2023-02-03 21:06
Reporter:	jstein	Platform:
Assigned To:	administrator	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	GARMIN Firmware images (new file format)
Description:	The format is documented on: https://www.memotech.franken.de/FileFormats/Garmin_GCD_Format.pdf You find examples here: https://www.gpsrchive.com/GPSMAP/GPSMAP%2066sr/Firmware.html#x-Firmware%20History-5.50 head gupdate.gcd | strings GARMINd Copyright 1996-2013 by Garmin Ltd. or its subsidiaries. @FYFRFKF head gupdate.gcd | hexdump 0000000 4147 4d52 4e49 0064 0001 0001 02dc 1500 0000010 0000 0000 0000 0000 0000 0000 0000 0000 0000020 0000 0000 0000 0003 0009 d410 135c 4504 0000030 140d 0541 3700 4300 706f 7279 6769 7468 0000040 3120 3939 2d36 3032 3331 6220 2079 6147 0000050 6d72 6e69 4c20 6474 202e 726f 6920 7374 0000060 7320 6275 6973 6964 7261 6569 2e73 0001 0000070 0001 024b 8900 000f 0000 0000 0000 0000 0000080 0000 0000 0000 0000 0000 0000 0000 0000 * 0001000 0001 0001 0664 0a00 0a00 1510 0920 0d10 0001010 0310 0750 0a00 0800 0000 0942 6e00 260e 0001020 0802 0000 08ff 9ff0 dae5 0f41 2c00 0a9b 0001030 2e00 0a9b 3c00 0600 0000 0000 f000 9db9 0001040 0f38 6246 e8c7 ffff ffff ffff c2ff 0941 0001050 0000 0000 6e00 000e 2600 2402 0000 c800 0001060 0c00 a080 14e1 9f01 00e5 a010 08e3 8010 0001070 00e5 a000 4ae3 0102 01eb a000 00e3 9f11 0001080 3ae5 0102 01eb a000 f8e3 9f10 29e5 0102 0001090 01eb a000 42e3 0102 01eb a000 e8e3 9f10 00010a0 32e5 0102 01eb a000 e0e3 9f10 21e5 0102 00010b0 00eb 0f00 1fe1 0000 13e2 5000 00e3 a080 00010c0 0003 a0b0 0003 a0a0 0003 a090 d103 a000 00010d0 00e3 21f0 b8e1 9fd0 d2e5 a000 00e3 21f0 00010e0 b0e1 9fd0 d3e5 a000 00e3 21f0 a8e1 9fd0 00010f0 dbe5 a000 00e3 21f0 a0e1 9fd0 d7e5 a000 0001100 00e3 21f0 98e1 9fd0 dfe5 a000 00e3 21f0 0001110 90e1 9fd0 02e5 a01a 10e3 011f 00ee a010 0001120 10e3 051f 17ee 071f 17ee 081f 10ee 120f 0001130 00ee a000 ffe1 ffff 10ea 110f 01ee 800a 0001140 10e3 010f 10ee 120f 00ee a000 ffe1 ffff 0001150 01ea 8f00 10e2 2fff 40e1 b2f0 27fa 84f0 0001160 40f9 5946 5246 4b46 0046 2524 261c 271c 0001170 a01c a146 a246 a346 1046 7ef0 46f9 19b0 0001180 0004 1e10 0010 ff00 00ff fe00 00ff ff10 0001190 00ff fe10 20ff fe00 20ff fe02 40ff fe02 00011a0 80ff fe02 60ff fe02 f0ff e8a9 6e02 5100 00011b0 75e3 00f5 700a 5100 eae3 00f5 660a 5100 00011c0 00e3 010b 650a 5100 fee3 000a
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
417	[file] General	feature	always	2023-01-17 01:29	2023-01-24 20:46
Reporter:	rebus	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.42
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	filetype for Microsoft OneNote files is not detected
Description:	File utility currently doesn't recognize the format of the OneNote files from Microsoft . As it starts to be used as a vector for spreading malware is becomes interesting to have the recognition for the format in the file utility.
Tags:	magic
Steps To Reproduce:	$ file test.one test.one: data
Additional Information:	OneNote files start with the magic bytes: - E4525C7B8CD8A74DAEB15378D02996D3 - for .one file = GUID {7B5C52E4-D88C-4DA7-AEB1-5378D02996D3} as specified by MS-ONESTORE - https://learn.microsoft.com/en-us/openspecs/office_file_formats/ms-onestore/405b958b-4cb7-4bac-81cc-ce0184249670 - A12FFF43D9EF764C9EE210EA5722765F - for the .onetoc2 filetype = GUID {43FF2FA1-EFD9-4C76-9EE2-10EA5722765F} as specified by the MS-ONESTORE and ONETOC2 - https://learn.microsoft.com/en-us/openspecs/office_file_formats/ms-onestore/2b394c6b-8788-441f-b631-da1583d772fd Mime type should be probably "application/onenote".
Attached Files:

Notes
(0003893) christos    2023-01-24 20:46	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
416	[file] General	minor	have not tried	2023-01-11 21:47	2023-01-24 20:37
Reporter:	thesamesam	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	Test failure on sparc
Description:	Running the test suite on Linux + sparc results in a test suite failure. Noticed with 5.44 but reproduced from git: ``` Running test: ../tests/fit-map-data TZ=UTC MAGIC=../magic/magic ./test -e ../tests/fit-map-data.testfile ../tests/fit-map-data.result ../tests/fit-map-data.testfile: FIT Map data, unit id 65536, serial 3879446968, Sat May 31 03:00:34 2014, manufacturer 1 (garmin), product 1632, type 4 (Activity) test: ERROR: result was (len 130) FIT Map data, unit id 65536, serial 3879446968, Sat May 31 03:00:34 2014, manufacturer 1 (garmin), product 1632, type 4 (Activity) expected (len 131) FIT Map data, unit id 65536, serial 3879446968, Sat May 31 10:00:34 2014, manufacturer 1 (garmin), product 1632, type 4 (Activity) make[2]: *** [Makefile:761: check-local] Error 1 make[2]: Leaving directory '/root/file/tests' make[1]: *** [Makefile:637: check-am] Error 2 make[1]: Leaving directory '/root/file/tests' make: *** [Makefile:465: check-recursive] Error 1 ``` I've attached the full log from `make check`. Let me know if I can give more information. Access to the environment is available if needed.
Tags:
Steps To Reproduce:
Additional Information:	# emerge --info Portage 3.0.42 (python 3.10.9-final-0, default/linux/sparc/17.0/64ul/desktop, gcc-12, glibc-2.36-r6, 5.15.69-gentoo sparc64) ================================================================= System uname: Linux-5.15.69-gentoo-sparc64-sun4v-with-glibc2.36 KiB Mem: 531346544 total, 402137592 free KiB Swap: 0 total, 0 free Timestamp of repository gentoo: Wed, 11 Jan 2023 21:02:13 +0000 sh dash 0.5.12 ld GNU ld (Gentoo 2.39 p5) 2.39.0 ccache version 4.7.4 [disabled] app-misc/pax-utils: 1.3.5::gentoo app-shells/bash: 5.2_p15::gentoo dev-lang/perl: 5.36.0-r1::gentoo dev-lang/python: 3.8.16::gentoo, 3.9.16::gentoo, 3.10.9::gentoo, 3.11.1::gentoo dev-lang/rust-bin: 1.65.0::gentoo dev-util/ccache: 4.7.4::gentoo dev-util/cmake: 3.25.1::gentoo dev-util/meson: 1.0.0::gentoo sys-apps/baselayout: 2.9::gentoo sys-apps/openrc: 0.45.2-r2::gentoo sys-apps/sandbox: 2.29::gentoo sys-devel/autoconf: 2.71-r5::gentoo sys-devel/automake: 1.16.5::gentoo sys-devel/binutils: 2.39-r4::gentoo sys-devel/binutils-config: 5.4.1::gentoo sys-devel/gcc: 10.4.1_p20221222::gentoo, 11.3.1_p20221223::gentoo, 12.2.1_p20221224::gentoo sys-devel/gcc-config: 2.8::gentoo sys-devel/libtool: 2.4.7-r1::gentoo sys-devel/make: 4.4::gentoo sys-kernel/linux-headers: 6.1::gentoo (virtual/os-headers) sys-libs/glibc: 2.36-r6::gentoo Repositories: gentoo     location: /bound/portage     sync-type: rsync     sync-uri: rsync://rsync.gentoo.org/gentoo-portage     priority: -1000     volatile: True     sync-rsync-verify-jobs: 1     sync-rsync-extra-opts:     sync-rsync-verify-max-age: 24     sync-rsync-verify-metamanifest: yes ACCEPT_KEYWORDS="sparc ~sparc" ACCEPT_LICENSE="@FREE" CBUILD="sparc64-unknown-linux-gnu" CFLAGS="-O2 -pipe -mcpu=ultrasparc" CHOST="sparc64-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -pipe -mcpu=ultrasparc" DISTDIR="/bound/distfiles" EMERGE_DEFAULT_OPTS="--complete-graph --with-bdeps=y --keep-going --deep --jobs=4" ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GDK_PIXBUF_MODULE_FILE GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR XDG_STATE_HOME" FCFLAGS="-O2 -pipe -mcpu=ultrasparc" FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs binpkg-multi-instance buildpkg-live cgroup config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe -mcpu=ultrasparc" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="C.UTF8" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu" LEX="flex" PKGDIR="/var/cache/binpkgs" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" PORTAGE_TMPDIR="/var/tmp" SHELL="/bin/bash" USE="X a52 aac acl alsa big-endian branding bzip2 cairo caps cdda cdr cli crypt cups dbus dri dts dvd dvdr encode exif filecaps flac fortran gdbm gif gmp gpm gtk gui iconv icu introspection ipv6 jit jpeg lcms libglvnd libnotify libtirpc llvm-libunwind mad mng mp3 mp4 mpeg ncurses nls nptl ogg opengl openmp pam pango pcre pdf png policykit ppds readline sdl sound sparc spell split-usr ssl startup-notification svg test-rust tiff truetype udev udisks unicode upower usb vorbis wxwidgets x264 xattr xcb xft xml xv xvid zlib" ADA_TARGET="gnat_2021" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="libinput" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LUA_SINGLE_TARGET="lua5-1" LUA_TARGETS="lua5-1" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-4 php8-0" POSTGRES_TARGETS="postgres12 postgres13" PYTHON_SINGLE_TARGET="python3_10" PYTHON_TARGETS="python3_10 python3_8 python3_9" RUBY_TARGETS="ruby27 ruby26" USERLAND="GNU" VIDEO_CARDS="dummy fbdev" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq proto steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: ADDR2LINE, AR, ARFLAGS, AS, ASFLAGS, CC, CCLD, CONFIG_SHELL, CPP, CPPFLAGS, CTARGET, CXX, CXXFILT, ELFEDIT, EXTRA_ECONF, F77FLAGS, FC, GCOV, GPROF, INSTALL_MASK, LC_ALL, LD, LFLAGS, LIBTOOL, LINGUAS, MAKE, MAKEFLAGS, MAKEOPTS, NM, OBJCOPY, OBJDUMP, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, RANLIB, READELF, RUSTFLAGS, SIZE, STRINGS, STRIP, YACC, YFLAGS
Attached Files:	file-test-suite.log (5,612 bytes) 2023-01-11 21:47 https://bugs.astron.com/file_download.php?file_id=320&type=bug

Notes
(0003888) thesamesam    2023-01-11 21:59	I've gone back to 5.39 and the same test fails consistently, which is weird because I feel like I would've noticed if it failed previously, as we have 5.43 marked stable on sparc in Gentoo.
(0003889) thesamesam    2023-01-12 07:19	I can't reproduce this in another container, I think something was wrong with the environment, as 'date' wouldn't respect TZ either. Apologies! Please close as invalid.
(0003892) christos    2023-01-24 20:37	The problem was that the test is printing localtime and your timezone is not what the tests expects (UTC). Forced in the test program now.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
418	[file] General	tweak	have not tried	2023-01-20 17:58	2023-01-24 20:30
Reporter:	joveler	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.44
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	Patch for HWP file format signature
Description:	This patch revises HancomOffice HWP (Hangul Word Processor) document file format signatures. HancomOffice HWP is a word processor (or semi-desktop publishing software) mainly used in the Republic of Korea. *Changes* 1. Add support for the HWPX format - Hancom is promoting that they are changing the most supported format to HWPX from HWP 5.0. - HWPX (OWPML) is based on OCF specification (PKZIP container), so the signature goes into magDir/archive. 2. Update filetype of HWP 3.0/5.0 format - HWP 3.0/5.0 filetype now starts with `Hancom HWP (Hangul Word Processor) file`. - Current HWP 3.0/5.0 format filetype contains `Hangul (Korean)`, but it is highly ambiguous.   In this context, Hangul is a trademarked name of the word processor, not Korean characters.   Also, the HWP formats do not have a distinction between Korean/Global HWP (program) releases. - I put the company name (Hancom) and program name (HWP), following the OOXML filetype convention (e.g. Microsoft Word 2007+).   I also added the full name of the HWP program, 'Hangul Word Processor', to avoid ambiguity between the program name and extension. - HWP 3.0 format is a proprietary binary format, so it had been in magDir/wordprocessors. - HWP 5.0 format uses MS compound data format similar to MS Office 97 ~ 2003.   The filetype string is hardcoded on src/readcdf.c, and also exists on magDir/ole2compounddocs. Both two files were patched. *Before Patch* ``` /c/Joveler/Build/Joveler.FileMagician/Joveler.FileMagician.Tests/Samples/HWP2016.hwp: Hangul (Korean) Word Processor File 5.x /c/Joveler/Build/Joveler.FileMagician/Joveler.FileMagician.Tests/Samples/HWP2016.hwpx: Zip data (MIME type "application/hwp+zip"?) /c/Joveler/Build/Joveler.FileMagician/Joveler.FileMagician.Tests/Samples/HWP97.hwp: Hangul (Korean) Word Processor File 3.0 ``` *After Patch* ``` /c/Joveler/Build/Joveler.FileMagician/Joveler.FileMagician.Tests/Samples/HWP2016.hwp: Hancom HWP (Hangul Word Processor) file, version 5.0 /c/Joveler/Build/Joveler.FileMagician/Joveler.FileMagician.Tests/Samples/HWP2016.hwpx: Hancom HWP (Hangul Word Processor) file, HWPX /c/Joveler/Build/Joveler.FileMagician/Joveler.FileMagician.Tests/Samples/HWP97.hwp: Hancom HWP (Hangul Word Processor) file, version 3.0 ```
Tags:	hwp hwpx magic
Steps To Reproduce:
Additional Information:
Attached Files:	file-5.44-hwp.diff (3,151 bytes) 2023-01-20 17:58 https://bugs.astron.com/file_download.php?file_id=321&type=bug HWP97.hwp (8,975 bytes) 2023-01-24 15:59 https://bugs.astron.com/file_download.php?file_id=322&type=bug HWP2016.hwp (9,216 bytes) 2023-01-24 15:59 https://bugs.astron.com/file_download.php?file_id=323&type=bug HWP2016.hwpx (14,377 bytes) 2023-01-24 15:59 https://bugs.astron.com/file_download.php?file_id=324&type=bug

Notes
(0003890) joveler    2023-01-24 15:59	Here are test sample files of the HWP format family.
(0003891) christos    2023-01-24 20:30	Committed, thanks

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
415	[file] General	minor	always	2023-01-04 14:50	2023-01-08 20:14
Reporter:	vt	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.44
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	ChangeLog.lz: empty (lzip compressed data, version: 1)
Description:	`FILE5_44`/`master`(at 8a07d6803554b25fbee28cd34bb0a0e7cea4cfd8) stopped to correctly detect file content inside of `lzip`'ed files. ``` file (master)$ src/file -S -z -m magic/magic.mgc ChangeLog.lz ChangeLog.lz: empty (lzip compressed data, version: 1) ```
Tags:
Steps To Reproduce:	``` file (master)$ lzip -k ChangeLog file (master)$ ls -la ChangeLog* -rw-r--r-- 1 vt vt 61943 Jan 4 17:41 ChangeLog -rw-r--r-- 1 vt vt 17529 Jan 4 17:39 ChangeLog.lz file (master)$ src/file -S -z -m magic/magic.mgc ChangeLog.lz ChangeLog.lz: empty (lzip compressed data, version: 1) ```
Additional Information:	`FILE5_43` was working correctly: ``` file ((FILE5_43))$ src/file -S -z -m magic/magic.mgc ChangeLog.lz ChangeLog.lz: ASCII text (lzip compressed data, version: 1) ```
Attached Files:

Notes
(0003887) christos    2023-01-08 20:14	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
414	[file] General	minor	always	2023-01-01 14:12	2023-01-08 17:11
Reporter:	arsenm	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.41
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	Missing handling for EM_AMDGPU and most other architectures
Description:	file does not recognize the e_machine type for AMDGPU and many other registered EM_* values. It reports this as "*unknown arch 0xe0*
Tags:
Steps To Reproduce:	$ file amdgpu.o amdgpu.o: ELF 64-bit LSB shared object, *unknown arch 0xe0* version 1, dynamically linked, not stripped Attached a random sample
Additional Information:	Grepping the sources suggests the list of handled cases is much smaller than the list of registered elf machines: src/readelf.h:#define EM_SPARC 2 src/readelf.h:#define EM_386 3 src/readelf.h:#define EM_SPARC32PLUS 18 src/readelf.h:#define EM_SPARCV9 43 src/readelf.h:#define EM_IA_64 50 src/readelf.h:#define EM_AMD64 62 The current list of registered target IDs is at https://www.sco.com/developers/gabi/latest/ch4.eheader.html, all of these should be recognized
Attached Files:	amdgpu.o (107,040 bytes) 2023-01-01 14:12 https://bugs.astron.com/file_download.php?file_id=319&type=bug

Notes
(0003886) christos    2023-01-08 17:11	These constants are not used for detection, they are used in code to provide custom hardware properties for specific processor architectures. The missing amdgpu was added in magic/Magdir/elf. Thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
409	[file] General	block	always	2022-12-12 16:37	2023-01-08 16:50
Reporter:	Girgias	Platform:	Linux
Assigned To:	christos	OS:	CentOS (Core)
Priority:	normal	OS Version:	7.9.2009
Status:	assigned	Product Version:	5.43
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Compilation error in softmagic.c due to redefining strndup in AIX preprocessor block
Description:	This was first reported to PHP here: https://github.com/php/php-src/pull/10074 The issue is located between lines 503 and 523 (https://github.com/file/file/blob/master/src/softmagic.c#L503-L523) Where the redeclaration of strndup probably should have been in an else block as otherwise the following compile errors can arise (line numbers inaccurate as it is the patched PHP version to use the PHP memory allocator): /www/server/source/php/php82/ext/fileinfo/libmagic/softmagic.c:507:7: error: expected identifier or ‘(’ before ‘extension’ char *strndup(const char *, size_t); ^ /www/server/source/php/php82/ext/fileinfo/libmagic/softmagic.c:510:1: error: expected identifier or ‘(’ before ‘extension’ strndup(const char *str, size_t n) ^ make: *** [libmagic/softmagic.lo] Error 1 make: *** [libmagic/softmagic.lo] Error 1
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003878) christos    2022-12-26 19:23	can you provide the preprocessor output cc -E of those lines?
(0003883) Girgias    2023-01-02 15:54	I've just asked the end-user if they can provide this information.
(0003884) Girgias    2023-01-08 15:49	End user came back with this:     gcc -E ext/fileinfo/libmagic/softmagic.c [root@VM-EtsmUAZgUPAH php82]# gcc -E ext/fileinfo/libmagic/softmagic.c # 1 "ext/fileinfo/libmagic/softmagic.c" # 1 "<built-in>" # 1 "<command-line>" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 1 "<command-line>" 2 # 1 "ext/fileinfo/libmagic/softmagic.c" # 32 "ext/fileinfo/libmagic/softmagic.c" # 1 "ext/fileinfo/libmagic/file.h" 1 # 36 "ext/fileinfo/libmagic/file.h" # 1 "ext/fileinfo/libmagic/config.h" 1 In file included from ext/fileinfo/libmagic/file.h:36:0,                  from ext/fileinfo/libmagic/softmagic.c:32: ext/fileinfo/libmagic/config.h:1:17: fatal error: php.h: No such file or directory  #include "php.h"                  ^ compilation terminated.     Compile time error libmagic/softmagic.dep -MT libmagic/softmagic.lo -fPIC -DPIC -o libmagic/.libs/softmagic.o In file included from /usr/include/string.h:633:0,                  from /www/server/php/82/include/php/main/../main/php_config.h:2207,                  from /www/server/php/82/include/php/Zend/zend_config.h:1,                  from /www/server/php/82/include/php/Zend/zend_portability.h:43,                  from /www/server/php/82/include/php/Zend/zend_types.h:25,                  from /www/server/php/82/include/php/Zend/zend.h:27,                  from /www/server/php/82/include/php/main/php.h:31,                  from /www/server/source/php/php82/ext/fileinfo/libmagic/config.h:1,                  from /www/server/source/php/php82/ext/fileinfo/libmagic/file.h:36,                  from /www/server/source/php/php82/ext/fileinfo/libmagic/softmagic.c:32: /www/server/source/php/php82/ext/fileinfo/libmagic/softmagic.c:507:7: error: expected identifier or ‘(’ before ‘__extension__’  char *strndup(const char *, size_t);        ^ /www/server/source/php/php82/ext/fileinfo/libmagic/softmagic.c:510:1: error: expected identifier or ‘(’ before ‘__extension__’  strndup(const char *str, size_t n)  ^ make: *** [libmagic/softmagic.lo] Error 1 Hopefully this is the requested information, and apologies for the delay.
(0003885) christos    2023-01-08 16:50	Unfortunately not, since the compilation terminated early because the user did not supply the correct -I path where php.h lives.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
411	[file] General	minor	always	2022-12-24 18:57	2022-12-28 17:50
Reporter:	yakov	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.43
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	Sony XAVC reported as application/octet-stream
Description:	The file utility does recognize "MPEG v4 system, Sony XAVC Codec", however it doesn't have a mime-type in the database. Consequently it's reported as application/octet-stream, which prevents xdg-open from opening those files with a video player. Probably reporting it as video/mp4 would be more appropriate.
Tags:	magic
Steps To Reproduce:
Additional Information:
Attached Files:	xavc.patch (422 bytes) 2022-12-26 20:25 https://bugs.astron.com/file_download.php?file_id=317&type=bug

Notes
(0003876) christos    2022-12-26 19:15	It is very difficult to recognize MPEG4, if you have some suggested magic, by all means, send it to me.
(0003880) yakov    2022-12-26 20:25	It's already recognized, but it's missing a mime-type; here's a patch.
(0003882) christos    2022-12-28 17:50	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
413	[file] General	block	always	2022-12-27 19:24	2022-12-28 17:48
Reporter:	grobian	Platform:	x86_64
Assigned To:	christos	OS:	OpenIndiana
Priority:	normal	OS Version:	2021.10
Status:	resolved	Product Version:	5.44
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	softmagic.c fails to compile due to undefined UINT_MAX
Description:	libtool: compile: x86_64-pc-solaris2.11-gcc -DHAVE_CONFIG_H -I. -I/gentoo/prefix64/var/tmp/portage/sys-apps/file-5.44/work/file-5.44/src -I.. -DMAGIC=\"/gentoo/prefix64/usr/share/misc/magic\" -fvisibility=hidden -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -Wformat=2 -O2 -pipe -c /gentoo/prefix64/var/tmp/portage/sys-apps/file-5.44/work/file-5.44/src/softmagic.c -fPIC -DPIC -o .libs/softmagic.o /gentoo/prefix64/var/tmp/portage/sys-apps/file-5.44/work/file-5.44/src/softmagic.c: In function ‘do_ops’: /gentoo/prefix64/var/tmp/portage/sys-apps/file-5.44/work/file-5.44/src/softmagic.c:1462:20: error: ‘UINT_MAX’ undeclared (first use in this function)  1462 | if (lhs >= UINT_MAX || lhs <= INT_MIN ||       | ^~~~~~~~ /gentoo/prefix64/var/tmp/portage/sys-apps/file-5.44/work/file-5.44/src/softmagic.c:46:1: note: ‘UINT_MAX’ is defined in header ‘<limits.h>’; did you forget to ‘#include <limits.h>’?    45 | #include "der.h"   +++ |+#include <limits.h>    46 | % gcc -dumpversion 12.2.0 % uname -a SunOS hollandscheleeuw 5.11 illumos-a7aaa5137d i86pc i386 i86pc Solaris Adding a patch as the compiler suggests makes it compile: % cat solaris.patch --- src/softmagic.c.orig 2022-12-27 20:05:39.006034099 +0000 +++ src/softmagic.c 2022-12-27 20:05:46.330774386 +0000 @@ -42,6 +42,7 @@  #include <ctype.h>  #include <stdlib.h>  #include <time.h> +#include <limits.h>  #include "der.h"    file_private int match(struct magic_set *, struct magic *, file_regex_t **, size_t, Please see attached patch. Thanks!
Tags:	build
Steps To Reproduce:	configure, make
Additional Information:
Attached Files:	file-5.44-solaris.patch (395 bytes) 2022-12-27 19:24 https://bugs.astron.com/file_download.php?file_id=318&type=bug

Notes
(0003881) christos    2022-12-28 17:48	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
410	[file] General	minor	always	2022-12-18 10:19	2022-12-26 19:21
Reporter:	pandrew	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.43
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	add support for bitcoin-core blk.dat, rev.dat, also .ldb files
Description:	Detect magic bytes and display basic data from the first header. For the LevelDB table data files, just detect the 64-bit magic number, no further processing. File attached and on github: https://github.com/pandrewhk/andrew/blob/master/magic/bitcoin
Tags:	magic
Steps To Reproduce:
Additional Information:
Attached Files:	bitcoin (669 bytes) 2022-12-18 10:19 https://bugs.astron.com/file_download.php?file_id=313&type=bug

Notes
(0003877) christos    2022-12-26 19:21	Added, thanks

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
412	[file] General	block	always	2022-12-26 18:37	2022-12-26 18:49
Reporter:	joveler	Platform:	MSYS2 MinGW-w64
Assigned To:	christos	OS:	Windows 10 22H2
Priority:	normal	OS Version:	gcc 12.2.0
Status:	resolved	Product Version:	5.43
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.45
		Target Version:
Summary:	file 5.43 compile error on MinGW/MSYS2 and fix
Description:	* This issue is continued from the 5.40 compile issue report, https://bugs.astron.com/view.php?id=255 file 5.43 needs patches to be compiled on MSYS MinGW-w64. [*] putc call In `file.c`, `fname_print()` has a code path dedicated for non-widechar support. MinGW-w64 goes into that route, and meets `putc` without any FILE* to write on. Simply adding `stdout` parameter solves the issue. ----- file.c: In function 'fname_print': file.c:605:25: error: too few arguments to function 'putc'   605 | putc(c);       | ^~~~ In file included from file.h:79,                  from file.c:32: C:/msys64/mingw64/include/stdio.h:705:15: note: declared here   705 | int __cdecl putc(int _Ch,FILE *_File);       | ^~~~ ----- [*] pipe call This issue is related to the previous 5.40 fcntl build error. Thanks to the official patch, 5.43 does not have any fcntl compile/link error on Windows. In spite of the fix, Windows C runtime does not provide `pipe()` function, creating a linker error. The proposed patch adds `__MINGW32__` check at the top of the function to mitigate this. ----- C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: .libs/funcs.o: in function `file_pipe_closexec': src/funcs.c:850: undefined reference to `pipe' ----- [*] ioctl call This issue is identical with the previous 5.40 ioctl build error. MinGW does not support ioctl call and produce a linker error. ----- C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/10.2.0/../../../../i686-w64-mingw32/bin/ld.exe: D:\Jang\Build\Source\PEBakery\Library\libmagic\file-5.40-mod\src/compress.c:417: undefined reference to `ioctl' ----- The proposed patch fixes this by adding !defined(__MINGW32__) check. If the library is configured with `--disable-xzlib --disable-bzlib`, the code is excluded and does not block the build.
Tags:	build, patch, Windows
Steps To Reproduce:	- Install MSYS2 on a Windows machine, and compile file source with normal `configure` and `make`.
Additional Information:	[*] Additional info of compile environment - Platform: Windows 10 22H2 with MSYS2 - Tested Target Arch : i686, x86_64, aarch64 - Toolchain: (1) MinGW-w64 of MSYS2 (i686/x86_64) (2) llvm-mingw (aarch64)
Attached Files:	MinGW_w64_putc_fix.diff (326 bytes) 2022-12-26 18:37 https://bugs.astron.com/file_download.php?file_id=314&type=bug MinGW_w64_ioctl_fix.diff (660 bytes) 2022-12-26 18:37 https://bugs.astron.com/file_download.php?file_id=315&type=bug MinGW_w64_pipe_fix.diff (374 bytes) 2022-12-26 18:37 https://bugs.astron.com/file_download.php?file_id=316&type=bug

Notes
(0003875) christos    2022-12-26 18:49	Committed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
404	[file] General	minor	always	2022-11-08 16:03	2022-12-09 18:02
Reporter:	manfredsc	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	reopened
Projection:	none
ETA:	none	Fixed in Version:	5.44
		Target Version:
Summary:	mime-types and extensions for GRIB
Description:	I would suggest enhancing the magic entries of "GRIB" with ext and mime items: in file magic/Magdir/meteorological: # https://en.wikipedia.org/wiki/GRIB 0 string GRIB >7 byte =1 Gridded binary (GRIB) version 1 !:mime application/x-grib !:ext grb/grib >7 byte =2 Gridded binary (GRIB) version 2 !:mime application/x-grib2 !:ext grb2/grib2
Tags:
Steps To Reproduce:
Additional Information:	For reasoning for the mime type, see https://tika.apache.org/1.28.5/formats.html and search for "grib" http://www.opengis.net/doc/IS/CIS-GRIB2/1.0 (search for "application/") suggests the mime-type "application/wmo-grib2" to be registered with IANA, but this never happened and is nowhere used in practice. Until then, it is recommended to use "application/x-grib2" (for the version 2 variant). For file suffixes, both the short and the long variants are used approximately equally often in practice, so I suggest adding both variants. The suffixes grb1 or grib1 are seldom used. As there is software which only can handle either GRIB1 or GRIB2 and not both, I suggest adding two separate mime entries and not merging them.
Attached Files:

Notes
(0003870) christos    2022-12-02 17:45	Thanks!
(0003871) manfredsc    2022-12-05 10:58	Thanks a lot. Your change resulted in # https://en.wikipedia.org/wiki/GRIB 0 string GRIB >7 byte >0 >>7 byte <3 Gridded binary (GRIB) version %d !:mime application/x-grib !:ext grb/grib I expected to get an entry for GRIB2, too. GRIB1 is a legacy format which is only seldom used nowadays. Since 2003 the successor GRIB2 is recommended to be used, and since about 10 years the overwhelming majority of weather agencies use GRIB2, in my view. Suffixes grb and grib are explicitly, exclusively used for GRIB1 datasets. The same goes for the mime type x-grib. Could we have some suffix and mime entries for GRIB2 too, please? There may be some vague dreams of a GRIB3, but this will most likely not manifest in the next 10 years, if at all. It is far more likely that some sort of XML or json format will be the successor of GRIB2, and it is not clear how this will be called.
(0003872) christos    2022-12-09 18:02	changed as suggested.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
405	[file] General	minor	always	2022-11-15 23:04	2022-12-02 17:42
Reporter:	eagr	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.43
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.44
		Target Version:
Summary:	Wrong mime for JPEG XL images
Description:	The mime type for JXL images has been incorrectly redefined as image/x-jxl by the b62c39d1e13a7547e634ce36272f94f3fd39cbc4 commit Instead, it should be defined as image/jxl - As such it used to be before the aforementioned commit - As provided by the URL in the magic/Magicdir/jpeg comment to the JXL-related definitions: http://fileformats.archiveteam.org/wiki/JPEG_XL - As there is no definition for image/x-jxl anywhere in the official JPEG XL reference implementation. There is, however, an image/jxl mime definition: https://github.com/libjxl/libjxl/blob/main/plugins/mime/image-jxl.xml The mistake causes image viewers such as XFCE Ristretto, that rely on file, to be unable to load JXL images because the gdk-pixbuf loader from the JXL reference implementation which they also employ only understands the image/jxl mime. https://github.com/libjxl/libjxl/tree/main/plugins/gdk-pixbuf
Tags:
Steps To Reproduce:	- Have installed ristretto and libjxl, jxl-pixbuf-loader as well if the distro provides the pixbuf loader in a separate package - Try open a JPEG XL image with ristretto Reproducible on a fresh archlinux install.
Additional Information:	Setting the JXL mime in magic/Magicdir/jpeg back to image/jxl makes things work again.
Attached Files:

Notes
(0003869) christos    2022-12-02 17:42	thanks

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
406	[file] General	crash	always	2022-11-27 18:00	2022-12-02 17:38
Reporter:	rwmjones	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.42
Product Build:		Resolution:	won't fix
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	seccomp support causes the -z option to fail on zstd-compressed files
Description:	"file" is been compiled with seccomp support. When we ask to inspect a zstd-compressed file with the -z option, it crashes: $ ./file-5.42/src/.libs/file -z /var/tmp/lib-i586.so.zst /var/tmp/lib-i586.so.zst: Bad system call
Tags:
Steps To Reproduce:	Please see attached zstd file. Just run the above command on it.
Additional Information:
Attached Files:	lib-i586.so.zst (1,712 bytes) 2022-11-27 18:00 https://bugs.astron.com/file_download.php?file_id=311&type=bug

Notes
(0003863) rwmjones    2022-11-27 18:00	This issue was originally reported by Toolybird here: https://github.com/libguestfs/libguestfs/issues/100#issuecomment-1328182986
(0003864) rwmjones    2022-11-27 18:03	Bad system call is possibly pipe2 ...? pipe2(0x7fff7c648048, O_CLOEXEC) = 293 +++ killed by SIGSYS +++ Bad system call (core dumped)
(0003865) rwmjones    2022-11-28 10:19	I've read about the -S option which the manual suggests combining with -z. Nevertheless it is possible to get it to work by enabling the following syscalls (quite a broad set): clone3 execve pipe2 prlimit64 wait4 I wonder if they could only be enabled when we know we're going to need to run a subcommand.
(0003868) christos    2022-12-02 17:38	If you enable clone and execve might as well turn off the sandbox. 5.43 gives you a better error message than bad system call. Fix the distribution provider to include the proper libraries instead.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
407	[file] General	minor	always	2022-11-28 15:06	2022-12-02 17:26
Reporter:	manfredsc	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.44
		Target Version:
Summary:	mime-type and extension not emitted for lzma
Description:	# file test.txt.lzma test.txt.lzma: LZMA compressed data, non-streamed, size 5 # file --mime-type test.txt.lzma test.txt.lzma: application/octet-stream # file --extension test.txt.lzma test.txt.lzma: ??? The magic entry is as follows [magic/Magdir/compress]: # Type: LZMA 0 lelong&0xffffff =0x5d >12 leshort 0xff LZMA compressed data, !:mime application/x-lzma !:ext lzma >>5 lequad =0xffffffffffffffff streamed >>5 lequad !0xffffffffffffffff non-streamed, size %lld >12 leshort 0 LZMA compressed data, >>5 lequad =0xffffffffffffffff streamed >>5 lequad !0xffffffffffffffff non-streamed, size %lld If the mime entry is moved to the end of the block, the mime description is given just fine. So I suggest moving the "!:mime" and "!:ext" lines to the end. # Type: LZMA 0 lelong&0xffffff =0x5d >12 leshort 0xff LZMA compressed data, >>5 lequad =0xffffffffffffffff streamed >>5 lequad !0xffffffffffffffff non-streamed, size %lld >12 leshort 0 LZMA compressed data, >>5 lequad =0xffffffffffffffff streamed >>5 lequad !0xffffffffffffffff non-streamed, size %lld !:mime application/x-lzma !:ext lzma With this, I get # file --mime-type test.txt.lzma test.txt.lzma: application/x-lzma # file --extension test.txt.lzma test.txt.lzma: lzma
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	test.txt.lzma (23 bytes) 2022-11-28 15:06 https://bugs.astron.com/file_download.php?file_id=312&type=bug

Notes
(0003866) manfredsc    2022-11-28 15:23	Or, other possibility would be to duplicate the mime and ext entries, I'm not familiar enough with the magic format to decide which is better: # Type: LZMA 0 lelong&0xffffff =0x5d >12 leshort 0xff LZMA compressed data, !:mime application/x-lzma !:ext lzma >>5 lequad =0xffffffffffffffff streamed >>5 lequad !0xffffffffffffffff non-streamed, size %lld >12 leshort 0 LZMA compressed data, !:mime application/x-lzma !:ext lzma >>5 lequad =0xffffffffffffffff streamed >>5 lequad !0xffffffffffffffff non-streamed, size %lld
(0003867) christos    2022-12-02 17:26	Fixed, thanks

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
400	[file] General	feature	N/A	2022-10-31 15:56	2022-11-06 18:47
Reporter:	lindblad	Platform:
Assigned To:	christos	OS:
Priority:	low	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.44
		Target Version:
Summary:	Haskell & Julia
Description:	Add detection of Haskell and Julia scripts. Haskell $ cat Hi.hs #!/usr/bin/env runghc main = putStrLn "hi!" $ cat Hello.hs #!/usr/bin/env runhaskell main = putStrLn "hello!" $ desired output simulated below $ file Hi.hs Hi.hs: GHC script, ASCII text executable $ file Hello.hs Hello.hs: Haskell script, ASCII text executable $ Julia $ cat Hello.jl #!/usr/bin/env julia println("hello world") $   desired output simulated below   $ file Hello.jl Hello.jl: Julia script, ASCII text executable $
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003860) christos    2022-11-06 18:47	Fixed, thanks

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
403	[file] General	minor	always	2022-11-06 10:04	2022-11-06 18:32
Reporter:	pinymantis	Platform:	Thinkpad
Assigned To:	christos	OS:	Linux
Priority:	normal	OS Version:	OpenSuse Leap 15
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.44
		Target Version:
Summary:	Any text file containing a line starting with "PROC" identified as Algol 68 source text
Description:	Note: This is related to https://bugs.astron.com/view.php?id=49 Any text file containing a line starting with "PROC" is identified as Algol 68 source text. This is at least irritating.
Tags:
Steps To Reproduce:	Run ``` #! /bin/bash echo "PROC" > t1 echo " PROC" > t2 echo "PROC " > t3 echo "PROCESSOR" > t4 echo "PROCX" > t5 cat << EOF > t6 MACHINE INFORMATION     Machine Manufacturer: LENOVO Machine Type-Model(MTM): XXXX Product Version: ThinkPad XXXX Serial Number: XXXX Eth Physical Address: XX-XX     BIOS INFORMATION     BIOS Version: N3EET22W (1.08 ) BIOS Release Date: 07/21/2022 BIOS Manufacturer: LENOVO EC Version: N3EHT18W(1.08) Intel ME Version: 16.1.25.1932     PROCESSOR INFORMATION XXXX XXXX ... EOF for f in t1 t2 t3 t4 t5 t6; do     file $f done ``` and the result will be t1: Algol 68 source, ASCII text t2: ASCII text t3: Algol 68 source, ASCII text t4: Algol 68 source, ASCII text t5: Algol 68 source, ASCII text t6: Algol 68 source, ASCII text
Additional Information:	test code `ptest` attached Motivation: Information from the UEFI-BIOS is UTF-16 encoded and needs to be converted to UTF-8 to be useful on (std) Linux.
Attached Files:	ptest (558 bytes) 2022-11-06 10:04 https://bugs.astron.com/file_download.php?file_id=310&type=bug

Notes
(0003859) christos    2022-11-06 18:32	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
402	[file] General	feature	always	2022-11-03 01:51	2022-11-04 13:36
Reporter:	Alan	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.43
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.44
		Target Version:
Summary:	Add support for Playdate native files
Description:	The Playdate portable video game console (https://play.date/) has several native file formats: pdi, pdt, pdv, pda, pdz, and pds. Currently file doesn't recognize any of them. The attached magic file adds support for them. Test data for many of these can be found in the free SDK https://play.date/dev/, and it can be used to create more.
Tags:	magic
Steps To Reproduce:
Additional Information:
Attached Files:	playdate-magic (1,538 bytes) 2022-11-03 01:51 https://bugs.astron.com/file_download.php?file_id=309&type=bug

Notes
(0003857) christos    2022-11-04 13:36	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
399	[file] General	minor	N/A	2022-10-30 12:25	2022-11-04 13:35
Reporter:	lindblad	Platform:
Assigned To:	christos	OS:
Priority:	low	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	reopened
Projection:	none
ETA:	none	Fixed in Version:	5.44
		Target Version:
Summary:	file typos
Description:	I recently cloned the GitHub mirror. The code appears to contain some typographical errors. The attached shell script is authorised for modification and/or use by the file utility developers.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	typos.sh (1,831 bytes) 2022-10-30 12:25 https://bugs.astron.com/file_download.php?file_id=308&type=bug

Notes
(0003855) christos    2022-10-31 14:24	Committed, thanks. Portability note: sed -i <pattern> is not portable; you should use sed -ie <pattern>. For example fails on macosx and bsd.
(0003856) lindblad    2022-10-31 15:26	I was using GNU sed, so thanks for the tip regarding sed -ie <pattern>. sed -i 's/alpabetical/alphabetic/g' file/magic/Magdir/msdos factually the above line should have read sed -i 's/alpabetical/alphabetical/g' file/magic/Magdir/msdos which would have resulted in the following # check for "long" alphabetical Lotus driver name like:

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
397	[file] General	major	always	2022-10-20 09:55	2022-10-27 19:20
Reporter:	dadv	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.43
Product Build:		Resolution:	reopened
Projection:	none
ETA:	none	Fixed in Version:	5.44
		Target Version:
Summary:	Regression in mode -f- (stdin)
Description:	Upto file-5.42 an application may popen("file -bnf-"), feed it with filenames and get results immediately. For example: (echo /lib/libc.so.7; sleep 3600) | file -bnf - Such command prints result immediately with file-5.42. file-5.43 does not print result immediately. It was broken with following commit: https://github.com/file/file/commit/19bf47777d0002ee884467e45e6ace702e40a4c1 Rollback of that commit fixes the regression.
Tags:	regression
Steps To Reproduce:	See above.
Additional Information:	The problem is serious as it breaks application that continuously feed "file -bnf-" with filenames and expect results at once, before EOF.
Attached Files:

Notes
(0003845) christos    2022-10-23 14:23	Added -I flag to address this.
(0003846) dadv    2022-10-23 20:18	Thank you very much for prompt response. Sadly, new flag still does not restore breakage of existing applications that rely on previous behaviour that existed for long time; applications would need to be modified and its is not always possible. Please consider adding new flag for new behaviour instead, so that "file -bnf-" would behave as before.
(0003848) christos    2022-10-24 20:19	I am guessing that there are very few applications that depend on this behavior (which was not guaranteed anyway). I think that it is better to have consistent output between:       cat foo | file -f - and       file -f foo as opposed to having them be different by default. If you want immediate results and inconsistent output, you should be explicit about it. Now that I think about it, there is nothing special about -f - vs -f /dev/stdin, so I better fix it to be also consistent.
(0003849) dadv    2022-10-25 02:07	Such applications do exist, nevertheless. Now they cannot just run "file" with same set of flags for any operating system, because different systems will have different "file" versions with different default behaviour for considerable time. # echo my.cnf | file -bnIf - file: invalid option -- I ASCII text Usage: file [-bcCdEhikLlNnprsSvzZ0] [--apple] [--extension] [--mime-encoding]             [--mime-type] [-e <testname>] [-F <separator>] [-f <namefile>]             [-m <magicfiles>] [-P <parameter=value>] [--exclude-quiet]             <file> ...        file -C [-m <magicfiles>]        file [--help]
(0003850) christos    2022-10-25 22:25	I am not very sympathetic of such apps. They could easily be converted to use libmagic. Running commands needlessly causes security issues (for example filenames with \n in them will not be processed correctly.
(0003851) dadv    2022-10-26 08:21	From the manual page:      -n, --no-buffer              Force stdout to be flushed after checking each file. This is              only useful if checking a list of files. It is intended to be              used by programs that want filetype output from a pipe. For me, it means that behaviour was "guaranteed".
(0003852) christos    2022-10-26 16:57	Here is a good point! I just used -n to restore the previous behavior and removed -I.
(0003854) dadv    2022-10-27 01:59	Thank you very much for this change. It really fixes compatibility. This PR can be closed now.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
398	[file] General	major	always	2022-10-25 22:36	2022-10-26 18:09
Reporter:	Fabrice	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.43
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.44
		Target Version:
Summary:	Build failure without wide support (e.g. on uclibc)
Description:	The build fails without wide support (e.g. on uclibc) since version 5.43 and https://github.com/file/file/commit/c80065fe6900be5e794941e29b32440e9969b1c3: file.c: In function 'fname_print': file.c:605:10: error: macro "putc" requires 2 arguments, but only 1 given   605 | putc(c);       | ^ Full log:  - http://autobuild.buildroot.org/results/7ff1dd9f79408d2e6286c005302b6f3c505ab259
Tags:	build, patch
Steps To Reproduce:
Additional Information:	The attaced patch will fix the build failure
Attached Files:	0001-src-file.c-fix-build-without-wide-support.patch (1,113 bytes) 2022-10-25 22:36 https://bugs.astron.com/file_download.php?file_id=307&type=bug

Notes
(0003853) christos    2022-10-26 18:09	Thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
387	[file] General	minor	always	2022-10-01 19:52	2022-10-24 19:50
Reporter:	rrt	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.43
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.44
		Target Version:
Summary:	!:strength sometimes causes magic to disappear
Description:	I was investigating a problem with Lua magic patterns. With the default Lua magic in CVS, I get these results: ``` $ MAGIC=./magic/magic src/file --list|grep "Lua script text executable" Strength = 51@11: Lua script text executable [text/x-lua] Strength = 49@15: Lua script text executable [text/x-lua] Strength = 48@13: Lua script text executable [text/x-lua] Strength = 45@9: Lua script text executable [text/x-lua] ``` This is correct: there are four patterns in the lua magic file. If I then add identical !:strength annotations to each entry, specifically "!:strength * 2", then one of the entries disappears (the one that should now have strength 96): ``` $ MAGIC=./magic/magic src/file --list|grep "Lua script text executable" Strength = 102@12: Lua script text executable [text/x-lua] Strength = 98@18: Lua script text executable [text/x-lua] Strength = 90@9: Lua script text executable [text/x-lua] ``` If I change the multiplier on the missing entry from 2 to 3, it returns: ``` $ MAGIC=./magic/magic src/file --list|grep "Lua script text executable" Strength = 144@15: Lua script text executable [text/x-lua] Strength = 102@12: Lua script text executable [text/x-lua] Strength = 98@18: Lua script text executable [text/x-lua] Strength = 90@9: Lua script text executable [text/x-lua] ```
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	lua.mgc (6,016 bytes) 2022-10-20 19:19 https://bugs.astron.com/file_download.php?file_id=306&type=bug

Notes
(0003825) christos    2022-10-09 17:23	Can you please upload the two different minimal magic files you are using to reproduce this?
(0003843) rrt    2022-10-20 19:19	I tried to make a minimal magic file, and in the process I obtained a similar strange result. When I compile just the CVS Lua magic file and then list its contents, I only get two text patterns, although the file contains four patterns. However, when I built the default "everything" magic file, it gives the expected four results. Here is the unexpected result: ``` $ ./src/file -C -m ./magic/Magdir/lua $ MAGIC=./lua.mgc src/file --list Set 0: Binary patterns: Strength = 70@19: Lua bytecode, [] Text patterns: Strength = 51@11: Lua script text executable [text/x-lua] Strength = 48@13: Lua script text executable [text/x-lua] Set 1: Binary patterns: Text patterns: ``` Note that there are only two text pattern results in Set 0. (I am not sure what Set 1 is?) If I run against the complete magic file, I get more patterns that can only come from the `lua` file: ``` $ MAGIC=./magic/magic.mgc src/file --list|grep text/x-lua Strength = 51@11: Lua script text executable [text/x-lua] Strength = 49@15: Lua script text executable [text/x-lua] Strength = 48@105: LuaTex script text executable [text/x-luatex] Strength = 48@13: Lua script text executable [text/x-lua] Strength = 45@9: Lua script text executable [text/x-lua] ``` In this set of results, only the LuaTex [sic] result is not from the `lua` file. I have attached the `lua.mgc` file produced by my system.
(0003844) christos    2022-10-23 13:23	Yes, the listing was skipping entries. I fixed it now. (apprentice.c 1.338).
(0003847) rrt    2022-10-24 10:03	Many thanks for the prompt fix!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
396	[file] General	minor	have not tried	2022-10-18 08:13	2022-10-18 14:12
Reporter:	mwfearnley	Platform:	Linux
Assigned To:	christos	OS:	Ubuntu (WSL)
Priority:	low	OS Version:	20.04.4 LTS
Status:	assigned	Product Version:	5.38
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	JS source file misdetected as JPEG2000
Description:	The source code at https://jplayer.org/latest/dist/jplayer/jquery.jplayer.min.js is misdetected as "JPEG 2000 image". The first six bytes ("/*! jP") is enough to trigger this identification.
Tags:
Steps To Reproduce:	$ wget https://jplayer.org/latest/dist/jplayer/jquery.jplayer.min.js $ file jquery.jplayer.min.js jquery.jplayer.min.js: JPEG 2000 image $ printf "/*! jP" > jp.txt $ file jp.txt jp.txt: JPEG 2000 image
Additional Information:
Attached Files:	jquery.jplayer.min.js (60,950 bytes) 2022-10-18 08:13 https://bugs.astron.com/file_download.php?file_id=304&type=bug jp.txt (6 bytes) 2022-10-18 08:13 https://bugs.astron.com/file_download.php?file_id=305&type=bug

Notes
(0003840) christos    2022-10-18 13:04	Can't reproduce in file 5.43.
(0003841) mwfearnley    2022-10-18 13:47	OK, thanks. I've managed to build the code from Github, and on a hunch I found the commit (and, I suspect, the removed line) that fixed it: https://github.com/file/file/commit/b62c39d1e13a7547e634ce36272f94f3fd39cbc4#diff-b5e20963b12b6811f0ca24ddd36790e9f3016bd5bb7af6083ca585c50ed34d4fL33 It's beyond my understanding (of JPEG 2000, or Quicktime formats, or of file itself) to say much more though.. Does it warrant a regression test?
(0003842) christos    2022-10-18 14:12	Sure, I just added one.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
389	[file] General	minor	have not tried	2022-10-01 20:11	2022-10-18 13:01
Reporter:	rrt	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.44
		Target Version:
Summary:	/usr/bin/env patterns should be stronger than more general patterns
Description:	In "varied.script" the /usr/bin/env patterns are annotated with "!:strength / 10", while the more general patterns that do not match /usr/bin/env get "!:strength / 2". This means that the /usr/bin/env-specific patterns never match first, which seems wrong.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003826) christos    2022-10-09 17:26	Can you show an example of incorrect behavior?
(0003838) rrt    2022-10-17 18:54	With current file CVS, with the file `foo.script` containing: ``` #!/usr/bin/env foo ``` I get the following output from file: ``` $ file foo.script foo.script: a /usr/bin/env foo script. ASCII text executable ``` If I run `file -k foo.script`, the second diagnosis is the one I would expect: ``` $ file -k foo.script foo.script: a /usr/bin/env foo script text executable\012- a foo script, ASCII text executable ```
(0003839) christos    2022-10-18 13:01	Fixed, thanks

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
388	[file] General	minor	have not tried	2022-10-01 20:09	2022-10-17 18:39
Reporter:	rrt	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Generic match for #! in "commands" file outweighs some language-specific matches
Description:	(Tested in current CVS) The pattern at around line 100 in "commands" say: ``` 0 string/wt #!\ a >&-1 string/T x %s script text executable ``` This gets strength 60. By contrast, the Lua-specific patterns in "lua" score between 40 and 50. Also, it's not obvious that this pattern should exist at all, as there are similar patterns in the "varied.script" file.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003827) christos    2022-10-09 17:53	I made all of them 30 and reorganized.
(0003837) rrt    2022-10-17 18:39	Thanks, some nice simplification here!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
395	[file] General	minor	always	2022-10-14 12:34	2022-10-16 13:00
Reporter:	saltedcoffii	Platform:	x86_64
Assigned To:	christos	OS:	Arch Linux
Priority:	normal	OS Version:	rolling
Status:	resolved	Product Version:	5.43
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.44
		Target Version:
Summary:	no magic for .tar.bz3 and .bz3 files
Description:	.tar.bz3 and .bz3 files created by the bzip3 utility are reported as “data” and “application/octet-stream”. They should proabably show up similarly to the .tar.bz2 and .bz2 files, e.g., “bzip3 compressed data, block size = <>" and “application/x-bzip3”
Tags:	compression, magic
Steps To Reproduce:	1. Compress a file using the bzip3 utility (or use the random data file provided) 2a. Read the file using `file <>.bz3` 2b. and `file --mime-type <>.bz3`
Additional Information:	External links: https://github.com/kspalaiologos/bzip3 https://aur.archlinux.org/packages/bzip3 https://pkgs.alpinelinux.org/package/edge/testing/x86_64/bzip3
Attached Files:	foo.bz3 (756,960 bytes) 2022-10-14 12:34 https://bugs.astron.com/file_download.php?file_id=302&type=bug 16.10.22-file-issue-0000395-files-to-help-devs.tar.gz (211,312 bytes) 2022-10-16 12:21 https://bugs.astron.com/file_download.php?file_id=303&type=bug

Notes
(0003835) saltedcoffii    2022-10-16 12:21	I realized that to find magic bytes, multiple files are required to compare and not all developers may have access to a compiled bzip3 yet. Here is a statically linked bzip3 v1.1.6 (latest version at the time of writing) for x86_64, and some files that have been randomly generated with `base64 /dev/random | head -c 10000` and compressed with `bzip3` and `tar`/`bzip3`. Also, how do developers find magic bytes? I work with file a lot, so I'm sure I could help if I knew how to find magic bytes for unsupported files. Let me know!
(0003836) christos    2022-10-16 13:00	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
394	[file] General	minor	always	2022-10-10 07:32	2022-10-10 18:46
Reporter:	ulm	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.43
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.44
		Target Version:
Summary:	Makefile misidentified as "PRO-PACK archive data", while file -i is correct
Description:	file-5.43 incorrectly reports "PRO-PACK archive data" for attached Makefile. "file -i" reports it correctly as text/x-makefile.
Tags:
Steps To Reproduce:	$ file Makefile Makefile: PRO-PACK archive data $ file -i Makefile Makefile: text/x-makefile; charset=us-ascii
Additional Information:
Attached Files:	Makefile (479 bytes) 2022-10-10 07:32 https://bugs.astron.com/file_download.php?file_id=301&type=bug

Notes
(0003833) ulm    2022-10-10 07:58	Here's some information about the Pro-Pack (aka RNC) header format: https://www.segaretro.org/Rob_Northen_compression Looks like requiring an additional byte 0x01 or 0x02 after "RNC" would mitigate the problem.
(0003834) christos    2022-10-10 18:46	Fixed. thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
304	[file] General	tweak	always	2021-12-06 06:32	2022-10-09 19:04
Reporter:	zachs18	Platform:
Assigned To:	christos	OS:
Priority:	low	OS Version:
Status:	resolved	Product Version:	5.41
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.44
		Target Version:
Summary:	Netpbm format does not correctly parse size for some images
Description:	The Netpbm image formats allow any amount of any whitespace between the width, height, and (if given) maxval fields in the header (it is only after the last field that exactly one whitespace character is allowed). The format specification in magic/Magdir/images, however, assumes that there is exactly one space character (\ ) between width and height. This leads file to not correctly parse the width and height in files where the width and height are separated by other whitespace, e.g. a newline, two spaces, or a tab.
Tags:	magic
Steps To Reproduce:	Place the below into a file (not including quotes): "P2 2 2 255 0 1 2 3" `file` will report the file as `Netpbm image data, size = 0 x 1, greymap, ASCII text`, instead of `Netpbm image data, size = 2 x 2, greymap, ASCII text`
Additional Information:	I believe this can be fixed by changing the regular expression on line 182 of magic/Magdir/images from "[0-9]{1,50}\ [0-9]{1,50}" to "[0-9]{1,50}[\040\t\f\r\n]+[0-9]{1,50}" Attached files are reported as: test1.pgm: `Netpbm image data, size = 0 x 0, greymap, ASCII text` test2.pgm: `, rawbits, greymap` but should be reported as: test1.pgm: `Netpbm image data, size = 2 x 2, greymap, ASCII text` test2.pgm: `Netpbm image data, size = 2 x 2, rawbits, greymap`
Attached Files:	test2.pgm (15 bytes) 2021-12-06 06:32 https://bugs.astron.com/file_download.php?file_id=250&type=bug test1.pgm (19 bytes) 2021-12-06 06:32 https://bugs.astron.com/file_download.php?file_id=251&type=bug

Notes
(0003684) christos    2021-12-17 14:43	Fixed as suggested, thanks!
(0003822) christos    2022-10-02 22:42	Fix Breaks: P3 # CREATOR: GIMP PNM Filter Version 1.1 10 20 255 255 (...)

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
337	[file] General	major	always	2022-04-05 19:06	2022-10-09 18:55
Reporter:	jmp3r	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.41
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Data files identified as text, text as data
Description:	new bug, based on previous tickets 0000319, 0000334 I used the latest sources (HEAD) from github I understand that it could be complicated to realize correct identifying text files but hope that its possible. Attached more files for test. Folders in archive: data - binaries (files encrypted with ransomware) detected as `Unicode text, UTF-16, big-endian text, with no line terminators` text - correct text files detected as data CORRECT_DETECTED_AS_DATA - one file similar to the others (in data folder) but identified correctly. If you need I can provide more files.
Tags:	bug
Steps To Reproduce:	Scan files from attach with `file` version latest sources (HEAD)
Additional Information:
Attached Files:	bug_new.zip (166,197 bytes) 2022-04-05 19:06 https://bugs.astron.com/file_download.php?file_id=272&type=bug

Notes
(0003748) christos    2022-05-22 20:01	It all has to do with the ucs16 detection in looks_ucs16 in encoding.c. if you change https://github.com/file/file/blob/master/src/encoding.c#L480 to 'return 0;', i.e. ignoring all ucs16 files that don't have BOM, then the text files mis-detected will get fixed (but then we'll miss usc16 files without BOM). The Estonian and Hebrew files have invalid low surrogate pair characters (dc00 and de05 respectively). If you comment out https://github.com/file/file/blob/master/src/encoding.c#L516, they succeed. The English.tr file has 2 0x13 (^S) characters, that is why it fails. The rest have some 0x7f DEL characters that is why they fail. If you comment out https://github.com/file/file/blob/master/src/encoding.c#L511, they all succeed.
(0003750) jmp3r    2022-05-27 22:56	Thank you for explanation. Now I'm trying to apply 3rd party (chardet / charset-normalizer) to detect text files. But what about files in `data` folder ? Files are encrypted but still detected as Unicode text ?
(0003751) christos    2022-05-28 00:27	This is the first sentence (about UCS16 files without BOM). If you comment out 480, they will all return data.
(0003752) jmp3r    2022-05-28 01:02	Oh, sry, didnt check correctly. Now I have `data` as I want and can handle them with postprocessing using `charset-normalizer` (pypi.org/project/charset-normalizer). Can I ask for future option (maybe post-processing for possible text files or replace current detection text data) that will provide results as good as charset-normalizer: for all encrypted (`data` folder) files we have correct `undefined` output: normalizer -m * Unable to identify originating encoding for "encry-https___download.eclipse.org_eclipse_updates_4.22_R-4.22-202111241800_p2.index". Maybe try increasing maximum amount of chaos. Unable to identify originating encoding for "encry-https___download.eclipse.org_technology_epp_packages_2021-12_202112021200_p2.index". Maybe try increasing maximum amount of chaos. Unable to identify originating encoding for "encry-https___download.eclipse.org_tools_cdt_releases_10.5_p2.index". Maybe try increasing maximum amount of chaos. Unable to identify originating encoding for "encry-led-20-headers.h". Maybe try increasing maximum amount of chaos. Unable to identify originating encoding for "encry-pom.properties". Maybe try increasing maximum amount of chaos. undefined undefined undefined undefined undefined and also for files in `text` folder: normalizer -m * utf_16 utf_16_le utf_16 utf_16_le utf_16 utf_16 utf_16 As you can see, all files detected 'closest to perfect' output
(0003832) christos    2022-10-09 18:55	Seems to be fine now.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
372	[file] General	minor	always	2022-07-30 14:24	2022-10-09 18:54
Reporter:	LevilJiang	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.44
		Target Version:
Summary:	allocation-size-too-big for file with ASAN
Description:	Hi dev I test the file with the latest commit (3d8a991) with AddressSanitizer. Unfortunately, it incurred a crash with the following error information. Any help would be greatly appreciated from you :D ``` ================================================================= ==123037==ERROR: AddressSanitizer: requested allocation size 0xffffffffffffff06 (0x708 after adjustments for alignment, red zones etc.) exceeds maximum supported size of 0x10000000000 (thread T0)     #0 0x55a7d202447e in __interceptor_malloc (/workspace/file/src/file+0xbf47e) (BuildId: 39c0b201f6cf154ce3a6ce6f762fe5e98224e3f3)     0000001 0x55a7d20bc640 in doshn readelf.c     0000002 0x55a7d20b865b in file_tryelf (/workspace/file/src/file+0x15365b) (BuildId: 39c0b201f6cf154ce3a6ce6f762fe5e98224e3f3)     0000003 0x55a7d208fdef in file_buffer (/workspace/file/src/file+0x12adef) (BuildId: 39c0b201f6cf154ce3a6ce6f762fe5e98224e3f3)     0000004 0x55a7d2064462 in file_or_fd magic.c     0000005 0x55a7d2064636 in magic_file (/workspace/file/src/file+0xff636) (BuildId: 39c0b201f6cf154ce3a6ce6f762fe5e98224e3f3)     0000006 0x55a7d2062232 in process file.c     0000007 0x55a7d205fed0 in main (/workspace/file/src/file+0xfaed0) (BuildId: 39c0b201f6cf154ce3a6ce6f762fe5e98224e3f3)     0000008 0x7f74af057d8f (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f) (BuildId: 89c3cb85f9e55046776471fed05ec441581d1969) ==123037==HINT: if you don't care about these errors you may set allocator_may_return_null=1 SUMMARY: AddressSanitizer: allocation-size-too-big (/workspace/file/src/file+0xbf47e) (BuildId: 39c0b201f6cf154ce3a6ce6f762fe5e98224e3f3) in __interceptor_malloc ==123037==ABORTING ``` Thanks & Best regards!
Tags:
Steps To Reproduce:	1. clone and build the file with AddressSanitizer from the Github repository 2. run the file binary with the attached crash input
Additional Information:
Attached Files:	crash_input (516 bytes) 2022-07-30 14:24 https://bugs.astron.com/file_download.php?file_id=293&type=bug

Notes
(0003792) christos    2022-07-30 18:12	What are you trying to do? Are you giving it a big elf file to identify?
(0003793) LevilJiang    2022-07-31 05:29	Actually, I adopted fuzzing testing to the file program and it generates the crash input. I'm not sure of the cause of allocation-size-too-big with the crash input.
(0003794) christos    2022-07-31 16:01	Ok, I committed a change to limit it to 128M. Does this work for you?
(0003795) LevilJiang    2022-08-01 03:06	Thanks very much!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
373	[file] General	minor	always	2022-08-02 18:58	2022-10-09 18:53
Reporter:	vismarli	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.34
Product Build:		Resolution:	reopened
Projection:	none
ETA:	none	Fixed in Version:	5.43
		Target Version:
Summary:	only match first out of multiple magic files
Description:	If we specify multiple magic files with "-m" and the file has matching from all of them, only the first magic with match will be evaluated, the rest will not be evaluated. for example, with "-m magicA:magicB:magicC" I observed the following: * if file has matching in magicA, magicB and magicC: only magicA will be evaluated * if file has matching in magicB and magicC : magicA and magicB will be evaluated, magicC won't be evaluated * if file has matching in magicC only : magicA, magicB and magicC will be evaluated not sure if this is expected behavior, from manual page it didn't mention any shortcut in evaluating multiple magic files nor any details of how multiple magic files will be evaluated.
Tags:
Steps To Reproduce:	$ cat magicA 0 search {\\rt1 RTF1.0 16 search ViVa2 Viva File 2.0 $ cat magicB 6 search ABCD ABCD File 10 search TesT Test File 1.0 $ xxd test-file-AB 0000000: 7b5c 7274 3120 4142 4344 5465 7354 2078 {\rt1 ABCDTesT x 0000010: 7856 6956 6132 xViVa2 $ file -km magicA test-file-AB test-file-AB: RTF1.0\012- Viva File 2.0, ASCII text, with no line terminators\012- data $ file -km magicB test-file-AB test-file-AB: ABCD File\012- Test File 1.0, ASCII text, with no line terminators\012- data $ file -km magicA:magicB test-file-AB test-file-AB: RTF1.0\012- Viva File 2.0, ASCII text, with no line terminators\012- data $ file -km magicB:magicA test-file-AB test-file-AB: ABCD File\012- Test File 1.0, ASCII text, with no line terminators\012- data
Additional Information:	$ file -d -km magicA:magicB test-file-AB [try zmagic 0] [try tar 0] [try cdf 0] [try elf 0] [try softmagic 0] bb=[0x1f37280,22], 0 [b=0x1f37280,22], [o=0, c=0] mget(type=20, flag=0x40, offset=0, o=0, nbytes=22, il=0, nc=0) mget/96 @0: \000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000 1: > 0 search,={\rt1,"RTF1.0"] 0 == 0 = 1 bb=[0x1f37280,22], 16 [b=0x1f37280,22], [o=0x10, c=0] mget(type=20, flag=0x40, offset=16, o=0, nbytes=22, il=0, nc=0) mget/96 @16: \000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000 2: > 16 search,=ViVa2,"Viva File 2.0"] 0 == 0 = 1 [try ascmagic 1] test-file-AB: RTF1.0\012- Viva File 2.0, ASCII text, with no line terminators\012- data $ file -d -km magicB:magicA test-file-AB [try zmagic 0] [try tar 0] [try cdf 0] [try elf 0] [try softmagic 0] bb=[0x794280,22], 6 [b=0x794280,22], [o=0x6, c=0] mget(type=20, flag=0x40, offset=6, o=0, nbytes=22, il=0, nc=0) mget/96 @6: \000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000 1: > 6 search,=ABCD,"ABCD File"] 0 == 0 = 1 bb=[0x794280,22], 10 [b=0x794280,22], [o=0xa, c=0] mget(type=20, flag=0x40, offset=10, o=0, nbytes=22, il=0, nc=0) mget/96 @10: \000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000 2: > 10 search,=TesT,"Test File 1.0"] 0 == 0 = 1 [try ascmagic 1] test-file-AB: ABCD File\012- Test File 1.0, ASCII text, with no line terminators\012- data
Attached Files:

Notes
(0003796) vismarli    2022-08-03 01:04	Intuitively if I specify multiple magic files e.g. "magicA:magicB", I expects libmagic to evaluate all rules from magicA+magicB combined/union-ed. But apparently its not that straightforward. Please tell me if its a bug or it's expected, can anyone clarify the behavior of multiple magic files via "-m" argument?
(0003797) vismarli    2022-08-16 14:40	Adding more clarifying information: * arguments to trigger this issue are: keep-going (-k) with multiple magic files specified in (-m) argument * the issue is always reproducible * this issue also occurs in latest version 5.42
(0003798) christos    2022-08-17 08:45	Fixed, thanks!
(0003801) vismarli    2022-08-17 16:03	thanks christos for the update, I can see all rules from multiple files are now hits correctly, but the output separator is not correct. I got something like this from testing with multiple magic "magicB:magicA" : MagicB-Rule1\012- MagicB-Rule2MagicA-Rule1\012- MagicA-Rule2, ASCII text, with no line terminators the "MagicB-Rule2" supposed to be separated from "MagicA-Rule1". I believe the "firstline" flag in match() should not be initialized to 1, it should be based on "need_separator" and "printed_something" flags.
(0003804) christos    2022-08-18 07:58	Yup, fixed.
(0003807) vismarli    2022-08-18 17:27	looks great now, thank you christos. you can close this ticket.
(0003831) christos    2022-10-09 18:53	Verified fixed.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
377	[file] General	minor	have not tried	2022-08-23 15:49	2022-10-09 18:52
Reporter:	standage	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Support TSV detection
Description:	It is very convenient that file and libmagic now support detection of CSV files. Files separated by tabs instead of commas are also very common. In fact, it's the de facto standard that UNIX shell tools use for pipeline compatibility: sort, cut, paste, and so on. In any case, being able to distinguish TSV files (mime type: text/tab-separated-values) from other unstructured ASCII text files would be a very useful feature. I hope it wouldn't be too difficult to extend the existing CSV support to support TSV.
Tags:
Steps To Reproduce:	$ file some.csv some.csv: CSV text $ file some.tsv some.tsv: ASCII text
Additional Information:
Attached Files:

Notes
(0003830) christos    2022-10-09 18:52	Yes, it is on the list of things to do :-)

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
390	[file] General	feature	always	2022-10-02 09:19	2022-10-09 18:51
Reporter:	cweiske	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.44
		Target Version:
Summary:	Detection for Frontier Silicon firmware downloads
Description:	Frontier Silicon (now Frontier Smart) is a company building chips that other companies build radios with. All of their firmware downloads have the same format, and they begin with 0x76110000 - see https://github.com/MatrixEditor/frontier-smart-api/blob/main/docs/firmware-2.0.md#11-header-structure The following magic line detects them: 0 belong 0x76110000 Frontier Silicon firmware download Example files can be found at https://github.com/cweiske/frontier-silicon-firmwares (ending with .isu.bin)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003829) christos    2022-10-09 18:51	Committed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
386	[file] General	minor	always	2022-10-01 06:18	2022-10-09 18:00
Reporter:	delphij	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.43
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	tests/gpkg-1-zst.result contains an extra \n
Description:	(I'm not 100% sure if this is a defect or not; it was discovered by FreeBSD CI, and https://ci.freebsd.org/job/FreeBSD-main-amd64-test/22193/testReport/usr.bin.file/file_test/contrib_file_tests/ is an example) So basically what our test cases does is that for each *.testfile under file's tests/, it does a "file --brief" on it and compare the trimmed output against the .result. The code can be found here: https://cgit.freebsd.org/src/tree/usr.bin/file/tests/file_test.sh In file 5.42, a test case was added for gpkg-1-zst.testfile, but the result contained an extra \n at the end, so the cmp would fail because the result is no longer exactly identical.
Tags:
Steps To Reproduce:	$ file --brief tests/gpkg-1-zst.testfile | tr -d '\012' > /tmp/actual $ cmp tests/gpkg-1-zst.result /tmp/actual cmp: EOF on /tmp/actual Expected result: cmp should give empty result.
Additional Information:	Proposed fix would be to remove the trailing \n so it matches the others: truncate -s 85 tests/gpkg-1-zst.result and possibly run the tests as part of CI process for file :) However, I am not 100% sure if the omission of the trailing \n's were intentional for these .result files. It took me some time to understand why the FreeBSD test case was removing the \n (https://cgit.freebsd.org/src/tree/usr.bin/file/tests/file_test.sh#n43). So please consider either applying this fix or changing all the .result files so that they have a trailing \n.
Attached Files:

Notes
(0003828) christos    2022-10-09 18:00	Added newlines to all result files for consistency.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
393	[file] General	minor	always	2022-10-09 05:41	2022-10-09 16:48
Reporter:	redshift	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.43
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	dsd64-dsf / JW07022A.mp3 tests failing with musl libc
Description:	In https://bugs.astron.com/view.php?id=382 an issue was reported for compiling file 5.43 against musl libc. I confirmed that finding. When I add the patch committed for issue 382 (https://github.com/file/file/commit/1294029cdb18d4c0997f2b52df435076b8444137) I don't get success but a different failure on the same test: ``` Running test: ../tests/dsd64-dsf.testfile ../tests/dsd64-dsf.testfile: DSF audio bitstream data mono, simple-rate, 1 bit, 141184 samples lt-test: ERROR: result was (len 65) DSF audio bitstream data mono, simple-rate, 1 bit, 141184 samples expected (len 94) DSF audio bitstream data, 1 bit, mono, "DSD 64" 2822400 Hz, no compression, ID3 version 2.3.0 ``` I used git bisect to check whether this is fixed by any later commit up to HEAD, and it's not, but there's one interesting thing - as soon as I hit the second-to-latest commit (https://github.com/file/file/commit/a960a2adb1c41ecb5b996390f2484035878c02f6) I get a different failure on a different test: ``` Running test: ../tests/JW07022A.mp3.testfile ../tests/JW07022A.mp3.testfile: Audio file with ID3 version 2.2.0, contains:MPEG ADTS, layer III, v1, 96 kbps, 44.1 kHz, Monaural lt-test: ERROR: result was (len 97) Audio file with ID3 version 2.2.0, contains:MPEG ADTS, layer III, v1, 96 kbps, 44.1 kHz, Monaural expected (len 99) Audio file with ID3 version 2.2.0, contains: MPEG ADTS, layer III, v1, 96 kbps, 44.1 kHz, Monaural ``` I suspected the test system stops on the first failure, so I removed the tests that run before dsd64-dsf to test whether it still fails, and it does. So, commit a960a2adb1 is adding additional failures, in this scenario. These failures are reproducible every time for me.
Tags:
Steps To Reproduce:	Build against musl libc; I'm on x86-64. I'm building for Void Linux which uses this build template - https://github.com/void-linux/void-packages/blob/master/srcpkgs/file/template - which does a fairly standard configure, make, make check, make install. Here's the full configure: ./configure --prefix=/usr --sysconfdir=/etc --sbindir=/usr/bin --bindir=/usr/bin --mandir=/usr/share/man --infodir=/usr/share/info --localstatedir=/var --host=x86_64-unknown-linux-musl --build=x86_64-unknown-linux-musl --libdir=${exec_prefix}/lib64 --enable-static --disable-libseccomp
Additional Information:
Attached Files:

Notes
(0003824) christos    2022-10-09 16:48	It's all been fixed now, thanks! It had nothing to do with muslc, it was broken magic and broken code.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
382	[file] General	minor	always	2022-09-15 14:32	2022-10-09 05:15
Reporter:	Marv	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.43
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.44
		Target Version:
Summary:	dsd64-dsf test fails with musl C library
Description:	When updating file from 5.42 to 5.43 on a system using the musl libc (version 1.2.3) the following test failure surfaced: ``` Running test: ../tests/dsd64-dsf.testfile ../tests/dsd64-dsf.testfile: DSD Stream File, mono, simple-rate, 1 bit, 141184 samples test: ERROR: result was (len 57) DSD Stream File, mono, simple-rate, 1 bit, 141184 samples expected (len 94) DSF audio bitstream data, 1 bit, mono, "DSD 64" 2822400 Hz, no compression, ID3 version 2.3.0 make[2]: *** [Makefile:738: check-local] Error 1 ``` It seems like the wrong magic information is picked since there are multiple definitions for "DSD\x20" at position 0: ``` magic/Magdir/dsf:7:0 string DSD\x20 DSD Stream File, magic/Magdir/audio:1230:0 string DSD\x20 DSF audio bitstream data ``` Any advice how to track this down further is appreciated as I'm not familiar with the codebase Best regards, Marvin
Tags:
Steps To Reproduce:	Build using the musl libc I used the following configure invocation: ``` ./configure --build=x86_64-pc-linux-musl --host=x86_64-pc-linux-musl --prefix=/usr/x86_64-pc-linux-musl --bindir=/usr/x86_64-pc-linux-musl/bin --sbindir=/usr/x86_64-pc-linux-musl/bin --libdir=/usr/x86_64-pc-linux-musl/lib --datadir=/usr/share --datarootdir=/usr/share --docdir=/usr/share/doc/file-5.43 --infodir=/usr/share/info --mandir=/usr/share/man --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-silent-rules --enable-fast-install --enable-bzlib --enable-xzlib --enable-zlib --disable-libseccomp --disable-static ```
Additional Information:
Attached Files:

Notes
(0003819) christos    2022-09-27 19:08	Merged duplicate entries.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
392	[tcsh] General	major	sometimes	2022-10-05 18:24	2022-10-05 18:24
Reporter:	RohanTalip	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:	6.21.00
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Segmentation faults on macOS Monterey 12.6
Description:	In one terminal window, after the issue seen in https://bugs.astron.com/view.php?id=391 was observed, typing commands that don't exist (initially accidentally) resulted in "Segmentation fault Exit 139" being printed (I have printexitvalue set). Later, trying to pipe the history to less also resulted in the same segmentation fault message, as did trying to use tab completion. I am not sure how related this is to https://bugs.astron.com/view.php?id=391 (maybe the issue with job control / pipes corrupted some memory) but it seemed different enough to warrant a separate bug report.
Tags:	bug
Steps To Reproduce:	Assume "%N" below is my prompt, and "#" starts a comment. %157 asdf list all nodejs | less # Success. %158 asdf list all nodejs | less [1] + Done asdf list all nodejs |        Suspended (tty output) /usr/local/bin/less [1] 34808 34809 %159 jobs [1] + Done asdf list all nodejs |        Suspended (tty output) /usr/local/bin/less %160 fg asdf list all nodejs | /usr/local/bin/less fg: No such job (badjob). Exit 1 %161 asdf list all nodejs | less # Success, I think. At least there was no exit status printed and no issue with the job control. %162 asdf list all nodejs | grep ^18 18.0.0 18.1.0 18.2.0 18.3.0 18.4.0 18.5.0 18.6.0 18.7.0 18.8.0 18.9.0 18.9.1 18.10.0 # I accidentally typed tsc (which if configured correctly will compile/transpile TypeScript files into JavaScript files) : %236 tsc tsc: Command not found. Segmentation fault Exit 139 %237 npx tsc # Success. %238 tsc tsc: Command not found. Segmentation fault Exit 139 # h is an alias for history: %335 h | less Segmentation fault Exit 139 # "h 10" works as expected: %337 h 10 %338 h | grep eslint | grep fix Segmentation fault Exit 1 %339 h | less Segmentation fault Exit 139 # gc is an alias for "git checkout"; I also have a completion for "gc"; trying to use tab completion resulted in "Segmentation fault" : %367 gc sr<TAB>Segmentation fault error: pathspec 'sr' did not match any file(s) known to git Exit 1 # Later: %460 gc ro<TAB>Segmentation fault %570 aabb aabb: Command not found. Segmentation fault Exit 139 %571 echo $version tcsh 6.21.00 (Astron) 2019-05-08 (x86_64-apple-darwin) options wide,nls,dl,bye,al,kan,sm,rh,color,filec %572 aaa aaa: Command not found. Segmentation fault Exit 139 %581 complete gc 'p/1/`git branch | cut -c 3-`/' # Other valid commands not requiring pipes or job control or tab completion seem to work fine.
Additional Information:	Other less long-lived tcsh sessions that have also seen the issue in https://bugs.astron.com/view.php?id=391 don't exhibit these segmentation fault issues: %42 aabb aabb: Command not found. Exit 1
Attached Files:

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
391	[tcsh] General	major	sometimes	2022-10-05 17:45	2022-10-05 17:45
Reporter:	RohanTalip	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:	6.21.00
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Job control or tty output does not work all the time on macOS Monterey 12.6
Description:	Either the job control or the tty output doesn't work roughly 1 in 30 times in tcsh 6.21.00 on macOS Monterey 12.6. tcsh 6.21.0 is the version that is installed on macOS Monterey 12.6. I also tried tcsh 6.24.01 from Homebrew ( https://formulae.brew.sh/formula/tcsh#default ), with similar results. I didn't notice the problem on macOS Monterey 12.5.1 or lower versions but maybe I didn't exercise the problem enough.
Tags:	bug
Steps To Reproduce:	Assume "%N" below is my prompt, and "..." represents omitted text or commands: %1 echo $version tcsh 6.21.00 (Astron) 2019-05-08 (x86_64-apple-darwin) options wide,nls,dl,bye,al,kan,sm,rh,color,filec %2 sleep 2 |& less %3 sleep 2 |& more %4 sleep 2 |& more % 5 sleep 1 |& more %6 which less less: aliased to /usr/local/bin/less %7 less --version less 608 (PCRE2 regular expressions) ... %8 sleep 1 |& less %9 sleep 1 |& less ... %31 vmstat |& less Exit 1 %32 iostat |& less ... % 34 iostat -c 10 |& less % 35 sleep 1 |& less % 36 sleep 1 |& less [1] + Done sleep 1 |&        Suspended (tty output) /usr/local/bin/less [1] 52209 52210 %37 jobs [1] + Done sleep 1 |&        Suspended (tty output) /usr/local/bin/less %39 less --version | head -1 less 608 (PCRE2 regular expressions) [1] + Done sleep 1 |&        Terminated /usr/local/bin/less %40 less --version | head -1 less 608 (PCRE2 regular expressions) %41 jobs # No jobs returned.
Additional Information:	Occasionally, typing "fg" after there is a "Exit 1" or a "Done" followed by a "Suspended (tty output)" in the job output that is reported when there is an error/problem, will result in the tcsh process taking up 100% of a CPU core, after which I have to kill it. Other times typing "fg" after such messages in the job output results in this message: "fg: No such job (badjob)."
Attached Files:

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
350	[tcsh] General	block	always	2022-05-27 09:02	2022-10-03 17:11
Reporter:	HKOB	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	new	Product Version:	6.21.00
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	complete: completion list words do not accept the `/` character.
Description:	It seems to me completion list words do not accept the `/` character. Escaping it does not seem to work. If there's a correct way to write such expression a small example would be nice, perhaps in the docs or in a test.
Tags:
Steps To Reproduce:	Example. Neither of these work to give the expected completion options a/a a/b a/c: ``` complete ml 'p/1/(a/a a/b a/c)/' complete ml 'p/1/"(a/a a/b a/c)"/' ```
Additional Information:
Attached Files:

Notes
(0003816) alzwded    2022-09-10 17:35	This seems to work ``` > complete ml 'p_1_(a/a b/b a/c)_' > ml^D a/a a/b a/c ``` The second character is considered the separator throughout (# seems to work as well). I'm not entirely sure where in that pretty long section on the `complete` builtin this note would go, I don't think I ever read every word in that section. I'm not sure what an autotest would test, it requires someone interactively triggering completion options; when you add a completion, it pretty much just stores the string as is and only evaluates it when needed. So 'man page' is probably the correct place to mention this.
(0003823) alzwded    2022-10-03 17:11	I was getting ready to update the man page, but re-reading the section more carefully, I noticed there already is a passing mention to alternative delimiters:                 [.........................] For example, the Elm mail program uses                `=' as an abbreviation for one's mail directory. One might use                    > complete elm c@=@F:$HOME/Mail/@                to complete `elm -f =' as if it were `elm -f ~/Mail/'. Note                that we used `@' instead of `/' to avoid confusion with the                select argument [...................]

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
385	[file] General	tweak	always	2022-09-27 10:10	2022-09-27 19:26
Reporter:	saltedcoffii	Platform:	x86_64
Assigned To:	christos	OS:	Arch Linux
Priority:	normal	OS Version:	rolling
Status:	resolved	Product Version:	5.43
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.44
		Target Version:
Summary:	Anki APKG files are not recognized separately from ZIP files
Description:	Anki (ankiweb.net) APKG files are compressed ZIP archives with exported flash card information, so that flash card sets from the app can be shared. From what I understand, libmagic sees the ZIP magic bytes and identifies it as a ZIP file, however this failure to recognize an APKG files has implications: on GNOME, double-clicking on an APKG file does not import the flash cards to Anki, if it is installed (expected behavior) but instead opens the archive in an archive manager, such as file-roller.
Tags:	filename, magic, zip
Steps To Reproduce:	1. Download any APKG file (many are available here https://ankiweb.net/shared/decks/) 2. run `file -mime-type <your filename>.apkg` and observe mimetype is not `application/x-apkg` but is `application/zip`
Additional Information:
Attached Files:

Notes
(0003821) christos    2022-09-27 19:26	Added magic for them, thanks

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
384	[file] General	minor	always	2022-09-25 15:48	2022-09-27 19:12
Reporter:	darose	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.43
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.44
		Target Version:
Summary:	Mime type application/x-ndjson misspelled as "x-ndjason"
Description:	This is a follow up from issue 0000359. That issue was resolved by recognizing JSON Lines files and identifying them as type "application/x-ndjson". However, the mimetype is being misspelled as "x-ndjason".
Tags:
Steps To Reproduce:	1. Upgrade "file" to v5.43 2. Run "file" on a valid JSON Lines file. 3. "file" will identify it as "application/x-ndjason" rather than "application/x-ndjson".
Additional Information:	See the following output for an example: $ cat /tmp/test.json {} {} $ pacman -Q file file 5.43-1 $ file -bz --mime-type /tmp/test.json application/x-ndjason
Attached Files:

Notes
(0003820) christos    2022-09-27 19:12	Fixed, thanks.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
381	[file] General	minor	always	2022-09-15 00:33	2022-09-27 19:05
Reporter:	vt	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.43
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.44
		Target Version:
Summary:	test.c:61:22: warning: use after 'free' of 's_17' [CWE-416] [-Wanalyzer-use-after-free]
Description:	GCC-12 static analyzer seems correctly report: ``` test.c: In function 'slurp': test.c:61:22: warning: use after 'free' of 's_17' [CWE-416] [-Wanalyzer-use-after-free]    61 | *s++ = c;       | ^ test.c:67:14: warning: use after 'free' of 's_18' [CWE-416] [-Wanalyzer-use-after-free]    67 | *s++ = '\0';       | ^ ``` Even thought this is just a test. ps. Also additional warning: ``` file.c: In function 'unwrap': file.c:550:25: warning: leak of 'flist_41' [CWE-401] [-Wanalyzer-malloc-leak]   550 | return 1;       | ^ ```
Tags:
Steps To Reproduce:	CFLAGS=-fanalyzer
Additional Information:
Attached Files:

Notes
(0003818) christos    2022-09-27 19:05	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
383	[file] General	minor	always	2022-09-25 04:27	2022-09-27 19:01
Reporter:	delphij	Platform:	arm64
Assigned To:	christos	OS:	FreeBSD
Priority:	normal	OS Version:	-CURRENT
Status:	resolved	Product Version:	5.43
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	printf %lc expects wint_t
Description:	In src/file.c, fname_print():         wchar_t nextchar; [...]                         printf("%lc", nextchar); but %lc expects wint_t, and this will cause build breakage for FreeBSD/arm64.
Tags:
Steps To Reproduce:	build with -Werror and -Wformat.
Additional Information:
Attached Files:	0001-file.c-Explicitly-cast-nextchar-to-wint_t-for-printf.patch (775 bytes) 2022-09-25 04:27 https://bugs.astron.com/file_download.php?file_id=300&type=bug

Notes
(0003817) christos    2022-09-27 19:01	fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
380	[file] General	crash	always	2022-09-01 14:23	2022-09-01 16:03
Reporter:	jmoyano	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	feedback	Product Version:	5.41
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	PDF file incorrectly reported as "data"
Description:	PDF files are incorrectly reported as "data" if the file has leading spaces in the "%PDF-" string   %PDF-1.4 <-- Notice the spaces at the beginning %���� 3 0 obj <</Type /Page /Parent 1 0 R /MediaBox [0 0 595.280 841.890] /TrimBox [0.000 0.000 595.280 841.890] /Resources 2 0 R...
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	boleta (5).pdf (60,395 bytes) 2022-09-01 14:23 https://bugs.astron.com/file_download.php?file_id=299&type=bug

Notes
(0003813) christos    2022-09-01 16:03	While it is easy to fix the magic recognition to ignore spaces, according to the spec https://opensource.adobe.com/dc-acrobat-sdk-docs/standards/pdfstandards/pdf/PDF32000_2008.pdf this is not a pdf file.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
379	[file] General	trivial	always	2022-08-30 17:33	2022-09-01 12:27
Reporter:	lvieirajr	Platform:	All
Assigned To:	christos	OS:	All
Priority:	normal	OS Version:	All
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.43
		Target Version:
Summary:	New python file-magic release
Description:	Hi, I'm sorry if this is not the correct place to mention this but it was the only location I could find. There has been a bug fixed on the python binding for file, that has been fixed for close to a year but has not been released yet as a new version to be downloaded on Pypi https://bugs.astron.com/view.php?id=285 It was supposed to be out whenever 0.4.1 came out, but that never happened. As you can see in here: https://pypi.org/project/file-magic/#history File-magic is still on version 0.4.0 Any chance we could get version 0.4.1 built and distributed to Pypi? This is an issue that we face daily while using file-magic.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003811) christos    2022-09-01 12:27	Release 0.4.1

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
363	[file] General	major	always	2022-07-01 01:55	2022-08-31 13:53
Reporter:	dimich	Platform:	x86_64
Assigned To:	christos	OS:	Linux
Priority:	normal	OS Version:	Arch Linux
Status:	resolved	Product Version:	5.42
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.43
		Target Version:
Summary:	Truncated filenames containing multibyte characters
Description:	Bugfix for issue 351 introduced new bug: filenames are truncated due to incorrect calculation of printable filename width. Filename width is calculated first in file_mbswidth() with respect to multibyte characters (first statement of #if/#endif), it uses iswprint() and handles multibyte characters correctly. Then filename is passed to file_printable() which uses simple isprint() and replaces every byte of multibyte character with 4 characters. Filename width is limited by previously calculated width (wid argument) and truncated, even in raw mode.
Tags:	bug, filename, multibyte
Steps To Reproduce:	$ touch файл.txt $ $ ls --zero | hexdump -b 0000000 321 204 320 260 320 271 320 273 056 164 170 164 000 000000d $ $ file файл.txt \321\204\320\260\320\271\320\273: empty $ $ file -r файл.txt файл: empty
Additional Information:	I think --raw option should not affect filenames at all. Non-printable characters may be replaced but at least with respect to multibyte encodings. See also issue 362.
Attached Files:	issue363.patch (2,036 bytes) 2022-07-01 03:10 https://bugs.astron.com/file_download.php?file_id=283&type=bug issue363-upd1.patch (3,308 bytes) 2022-07-01 04:20 https://bugs.astron.com/file_download.php?file_id=284&type=bug issue363-upd2.patch (3,406 bytes) 2022-07-01 06:43 https://bugs.astron.com/file_download.php?file_id=285&type=bug

Notes
(0003771) dimich    2022-07-01 03:10	This patch seems fix the issue
(0003772) dimich    2022-07-01 04:20	Updated patch: handle invalid sequences in filenames and multicolumn characters.
(0003773) dimich    2022-07-01 06:43	One more try :) Do not replace invalid sequence characters in raw mode, print as is. The only issue i found is when --raw mode is on, --no-pad is off, LC_CTYPE=C (or another 1-byte encoding) and console is UTF-8. In this case field width cannot be calculated correctly: we don't know how many character cells a sequence will take. Possible solution is to force --no-pad in --raw mode.
(0003780) christos    2022-07-04 19:46	Dup for PR/362
(0003782) christos    2022-07-04 20:16	I like your idea to print invalid as octal, so I applied to my patch.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
376	[file] General	minor	always	2022-08-22 10:17	2022-08-23 08:01
Reporter:	bsevens	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.42
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.43
		Target Version:
Summary:	Commit 43f7989076aa3731f3558c6954780bc7b2734b64 broke VHD detection
Description:	Commit 43f7989076aa3731f3558c6954780bc7b2734b64 (https://github.com/file/file/commit/43f7989076aa3731f3558c6954780bc7b2734b64) aimed at fixing spelling errors, but also included changes to some file signatures. E.g. `conectix` was changed to `connectix`, which means Microsoft Disk Images are currently not detected by file.
Tags:
Steps To Reproduce:	$ echo connectix > /tmp/wrong.vhd $ file /tmp/wrong.vhd /tmp/wrong.vhd: Microsoft Disk Image, Virtual Server or Virtual PC, 0 bytes, type 0, State 0 $ echo conectix > /tmp/correct.vhd $ file /tmp/correct.vhd /tmp/correct.vhd: ASCII text
Additional Information:
Attached Files:

Notes
(0003808) christos    2022-08-23 08:01	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
375	[file] General	major	always	2022-08-08 18:07	2022-08-18 08:08
Reporter:	DC	Platform:	Linux
Assigned To:	christos	OS:	Gentoo
Priority:	high	OS Version:	Latest
Status:	resolved	Product Version:	5.42
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.43
		Target Version:
Summary:	Broken output for national characters
Description:	Since version 5.42 the file command doesn't output correctly files with national characters in the path: $ file -v file-5.42 magic file from /usr/share/misc/magic seccomp support included $ file /tmp/ěščřžýáíé/file.txt /tmp/\304\233\305\241\304\215\305\231\305\276\303\275\303\241\303\255\303\251: ASCII text File version 5.41 is working fine: $ file -v file-5.41 magic file from /usr/share/misc/magic seccomp support included $ file /tmp/ěščřžýáíé/file.txt /tmp/ěščřžýáíé/file.txt: ASCII text My locales are: LANG=cs_CZ.UTF-8 LC_ALL=cs_CZ.UTF-8
Tags:	bug, filename
Steps To Reproduce:	Run the file command on file with national characters in the path.
Additional Information:
Attached Files:

Notes
(0003800) christos    2022-08-17 08:56	How do you reproduce it? bash-3.2$ touch /tmp/ěščřžýáíéfile.txt bash-3.2$ ./file -m ../magic/magic.mgc /tmp/*.txt /tmp/ěščřžýáíéfile.txt: empty bash-3.2$ file -v file-5.42 magic file from /usr/local/share/misc/magic
(0003802) lilydjwg    2022-08-18 04:17	I get this issue with Chinese characters too. christos, you checked the version of a wrong file binary?
(0003803) christos    2022-08-18 06:40	I am running with the version from the HEAD of the tree which is different. Can you try that?
(0003805) DC    2022-08-18 08:05	I confirm that when I build the file binary from latest sources then everything seems to be working fine again!
(0003806) christos    2022-08-18 08:08	Great, let me close this and plan for a new release! Thanks for testing.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
374	[file] General	major	always	2022-08-06 15:53	2022-08-17 08:48
Reporter:	piru	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.42
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.43
		Target Version:
Summary:	Endless busyloop in file_mbswidth
Description:	file_mbswidth contains an endless bysyloop in the non-widechar version. The bug is in the while loop:     while (*s) {         width += (ms->flags & MAGIC_RAW) != 0             || isprint(CAST(unsigned char, *s)) ? 1 : 4;     } ref: https://github.com/file/file/blob/e1233247bbe4d2d66b891224336a23384a93cce1/src/file.c#L678 Note that variable `s' is not incremented at all. Fix is easy, add s++; to the loop.
Tags:
Steps To Reproduce:	1. Build file for system without widechar support 2. file anyfile
Additional Information:	This bug was added by commit https://github.com/file/file/commit/f448f3e5c37de8c285ac14b032b2bdcea82fc08b
Attached Files:

Notes
(0003799) christos    2022-08-17 08:48	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
99	[tcsh] General	minor	always	2019-08-13 14:44	2022-08-09 09:53
Reporter:	xdelaruelle	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:	6.21.00
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	use of :q in back-tick context leads to erroneous extra history entries
Description:	I am developing a tool called Modules (http://modules.sourceforge.net/) which enables to dynamically update user's shell environment. In short, this tool provides a shell alias called `module` which evaluates in the current shell the output of a script producing shell code. The `module` command is currently defined this way:   $ alias module 'eval "`/usr/share/Modules/libexec/modulecmd.tcl tcsh \!*:q`"' Which leads to erroneous entries in the ~/.history file:   #+1565705427   module load foo bar   #+1565705427   load foo bar#+1565705430   history All arguments passed from the alias to the modulecmd.tcl script are added as a second history line. These erroneous entries seem to come from the use of the quote modifier `:q` within a back-tick context ``. Some explanation on the use of the quote modifier :q in this alias: as the modulecmd.tcl script outputs shell codes, it contains sometime special characters like curly braces, so the result of the script execution is enclosed in double quotes to pass it to eval. In this situation to correctly obtain quoted arguments, the quote modifier is used. The issue has been reproduced on tcsh versions 6.18, 6.19, 6.20 and 6.21.
Tags:
Steps To Reproduce:	To reproduce the issue on a small example, here is a script that produces some shell code (to define an alias or set an environment variable): $ cat ./dispatch #!/bin/csh if ( $#argv != 1 ) then   echo echo should get exactly 1 arg   exit 1 endif switch ( $argv[1] ) case myname:   echo alias myname getent\\ passwd\\ \\\$USER\ \\\|\\ awk\\ -F:\\ \\\'\\\{print\ \\\$5\\\}\\\';   breaksw; case "":   echo setenv EMPTY 1;   breaksw; endsw $ echo $tcsh 6.21.00 Here we define the shell alias that calls the script and evaluates the shell code this script outputs: $ alias tuneenv 'eval "`./dispatch \!*:q`"' Then we use the alias: $ tuneenv "" $ echo $EMPTY 1 $ tuneenv myname $ myname Xavier $ exit Looking at history file, erroneous entries can be seen: $ tail ~/.history #+1565702553 tuneenv "" #+1565702553 ""#+1565702559 echo $EMPTY #+1565702565 tuneenv myname #+1565702565 myname#+1565702567 myname
Additional Information:	Some additional tests to demonstrate the need to enclose script result in double quotes to pass it to eval: $ alias tuneenv 'eval `./dispatch \!*`' $ tuneenv myname Missing '}'. So without the double quotes, the shell alias myname which contains curly braces cannot be set Then if we enclose script result in double quotes, !* should get the quote modifier applied to correctly transmit quoted arguments: $ alias tuneenv 'eval "`./dispatch \!*`"' $ tuneenv myname $ myname Xavier $ tuneenv "" should get exactly 1 arg Without :q, the "" argument is not transmitted to the dispatch script.
Attached Files:	dispatch (279 bytes) 2019-08-13 14:44 https://bugs.astron.com/file_download.php?file_id=72&type=bug

Notes
(0003317) christos    2019-10-19 18:54	Sorry, I can't reproduce it with 6.21.00 on either Linux or NetBSD. Did that break with 6.21.00 or the bug was always there?
(0003318) xdelaruelle    2019-10-20 15:21	I get the exact same result whether I test this on tcsh version 6.18, 6.19, 6.20 and 6.21 on a Linux system. Here are the details of the tcsh 6.21.00 ran: $ echo $version tcsh 6.21.00 (Astron) 2019-05-08 (x86_64-unknown-linux) options wide,nls,dl,al,kan,sm,rh,color,filec With that shell, applying code sequence described in 'Steps To Reproduce' section with dispatch script attached to this ticket (shebang adapted to match the tcsh shell ran), the same erroneous ~/.history file is obtained (as described in section).

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
371	[file] General	minor	always	2022-07-27 20:56	2022-07-30 18:07
Reporter:	Mark.Taylor	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.42
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.43
		Target Version:
Summary:	magic type returned is 100% bogus: ", utcTime=2073-\0120-.0 23:85:8\012 GMT"
Description:	Tested using Mac `file` 5.41, Linux `file` 5.37, 5.38, and 5.42: a sample text file containing floating point numbers returns a bogus magic type, as in ", utcTime=2073-\0120-.0 23:85:8\012 GMT". 0.000252 0.065583 0.024648 0.028474 0.024969 0.024273 0.031606 0.024479 0.02417 0.024741 0.024859 0.024396 0.027473 0.023858 0.024483 0.024377 0.032009 0.024065 0.024564
Tags:
Steps To Reproduce:	Put the above, or the include d/l file, and run `file` on it - it should return `ASCII text`, but instead it returns the indicated string. Note that on a Mac with 5.41 it returns: # file x.txt x.txt: , not-valid-before=2073- 0-.0 23:85:8  GMT
Additional Information:	Not including "soft" (`file -e soft`) makes the return `ASCII text` as expected. Note that I tracked it down to a problem in softmagic.c:match() when it was working on either magindex 14184 or 14231 (skipping both of those seems to make it DTRT).
Attached Files:	x.txt (170 bytes) 2022-07-27 20:56 https://bugs.astron.com/file_download.php?file_id=292&type=bug

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
370	[file] General	trivial	have not tried	2022-07-25 17:54	2022-07-30 17:06
Reporter:	phll4	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.43
		Target Version:
Summary:	Typo for "PhotometricIntepretation"
Description:	magic/Magdir/images contains a typo in the word "PhotometricIntepretation" which should be "PhotometricInterpretation" (additional "r": PhotometricInte**r**pretation). Link to the code mirror on GitHub of the line in current master: https://github.com/file/file/blob/1c9f670f69bd508da2b4d05a28d27bd92407f2c8/magic/Magdir/images#L368
Tags:
Steps To Reproduce:
Additional Information:	The same typo did exist in libtiff, at least in the manpage of tiffgt at some point (old version is still online at http://www.libtiff.org/man/tiffgt.1.html). Current tiffgt does NOT have the typo anymore: https://gitlab.com/libtiff/libtiff/-/blob/master/doc/tools/tiffgt.rst Nor does it exist anywhere in modern libtiff: https://gitlab.com/search?search=PhotometricIntepretation&nav_source=navbar&project_id=4720790&group_id=2221836&search_code=true&repository_ref=master
Attached Files:

Notes
(0003791) christos    2022-07-30 17:06	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
369	[file] General	minor	always	2022-07-21 15:00	2022-07-30 17:04
Reporter:	hbent	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.42
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.43
		Target Version:
Summary:	src/vasprintf.c typo fix
Description:	src/vasprintf.c line 638 is: memcpy (&s.vargs, &vargs, sizeof (s.va_args)); should be memcpy (&s.vargs, &vargs, sizeof (s.vargs));
Tags:
Steps To Reproduce:	Attempt to compile on a platform that lacks va_copy
Additional Information:	Found on alphaev56-dec-osf5.1b
Attached Files:

Notes
(0003790) christos    2022-07-30 17:04	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
366	[file] General	feature	N/A	2022-07-10 23:25	2022-07-17 15:36
Reporter:	polluks	Platform:	MacBookPro17,1
Assigned To:	christos	OS:	macOS
Priority:	normal	OS Version:	12.3.1
Status:	resolved	Product Version:	5.42
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.43
		Target Version:
Summary:	Added to xo65
Description:	The simulator files are missing so far.
Tags:
Steps To Reproduce:
Additional Information:
System Description	Apple M1
Attached Files:	xo65 (1,154 bytes) 2022-07-10 23:25 https://bugs.astron.com/file_download.php?file_id=288&type=bug

Notes
(0003789) christos    2022-07-17 15:36	Added, thanks

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
367	[file] General	feature	always	2022-07-14 16:14	2022-07-17 15:33
Reporter:	Mytherin	Platform:
Assigned To:	christos	OS:
Priority:	low	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.43
		Target Version:
Summary:	Add detection of DuckDB database files
Description:	DuckDB is an open source database system, similar to SQLite but focused on analytical workloads: https://github.com/duckdb/duckdb This patch adds detection for database files generated by DuckDB. Attached is an example database file.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	duckdb.magic.patch (346 bytes) 2022-07-14 16:14 https://bugs.astron.com/file_download.php?file_id=289&type=bug example-duckdb.db (274,432 bytes) 2022-07-14 16:14 https://bugs.astron.com/file_download.php?file_id=290&type=bug

Notes
(0003788) christos    2022-07-17 15:33	added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
368	[tcsh] General	minor	always	2022-07-15 19:09	2022-07-15 19:09
Reporter:	untitled	Platform:	amd64
Assigned To:		OS:	FreeBSD, Linux
Priority:	normal	OS Version:	all
Status:	new	Product Version:	6.23.00
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Pipe error
Description:	vmstat -m | head -n 1 && vmstat -m | grep smtn_present does not _always_ show the output of the second command, but prints only the headers. The main word here is "always", as sometimes it works fine, but sometimes shows only the headers of vmstat. When commands are separated with a semicolon, everything works fine. Also vmstat -m | head -n 1 || vmstat -m | grep smtn_present sometimes shows output from both commands. Tested on FreeBSD and Debian linux.
Tags:
Steps To Reproduce:	- log into tcsh - vmstat -m | head -n 1 && vmstat -m | grep smtn_present - enter the command many-many times and see the different results
Additional Information:
Attached Files:	Screenshot 2022-07-15 at 22.09.23.png (768,709 bytes) 2022-07-15 19:09 https://bugs.astron.com/file_download.php?file_id=291&type=bug

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
365	[file] General	feature	always	2022-07-09 11:04	2022-07-09 16:12
Reporter:	wof	Platform:
Assigned To:	christos	OS:
Priority:	low	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.43
		Target Version:
Summary:	add detection of Unison archive format
Description:	Unison Two-way cross-platform file synchronizer. To store the current state after a sync, unison creates archive files. (see. https://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#archives) This patch adds detection for this file type. The unison project can be found on https://github.com/bcpierce00/unison
Tags:
Steps To Reproduce:	% file ar1a68e37cd2df302f691f0881c17b2074 ar1a68e37cd2df302f691f0881c17b2074: data
Additional Information:
Attached Files:	ar1a68e37cd2df302f691f0881c17b2074 (6,624 bytes) 2022-07-09 11:04 https://bugs.astron.com/file_download.php?file_id=286&type=bug unison.magic.patch (880 bytes) 2022-07-09 11:04 https://bugs.astron.com/file_download.php?file_id=287&type=bug

Notes
(0003787) christos    2022-07-09 16:12	Added to archive.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
364	[file] General	minor	always	2022-07-05 14:24	2022-07-07 17:20
Reporter:	mam-ableton	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.43
		Target Version:
Summary:	Truncated "from" string when processing QEMU ELF coredumps
Description:	File shows incorrect output when processing ELF coredumps created by QEMU. Here is example output: root@489a926e3c6b:/ci/test-arm# file qemu_segfault-arm-more-than-sixteen-chars_20220701-162324_884.core qemu_segfault-arm-more-than-sixteen-chars_20220701-162324_884.core: ELF 32-bit LSB core file, ARM, version 1 (SYSV), SVR4-style, from 'segfault-arm-mor./segfault-arm-more-than-sixteen-chars', real uid: 0, effective uid: 0, real gid: 0, effective gid: 0, execfn: './segfault-arm-more-than-sixteen-chars', platform: 'v8l' Note this specific part: "from 'segfault-arm-mor./segfault-arm-more-than-sixteen-chars" It should actually say: "from './segfault-arm-more-than-sixteen-chars" This is two separate strings that have been incorrectly concatenated: "segfault-arm-mor" and "./segfault-arm-more-than-sixteen-chars" The first string comes from the `pr_fname` member of the `struct elf_prpsinfo`. It is a 16 byte char buffer that contains the first 16 bytes of the filename. It is not required to be NULL terminated, *although Linux does*. QEMU does not in its coredumps — if the filename is >=16 characters, there is no NULL separating this buffer from `pr_psargs` (described next). The second string comes from the immediate following struct member, `pr_psargs`, an 80 byte char buffer with the argv strings. See struct definition here: https://github.com/torvalds/linux/blob/c1084b6c5620a743f86947caca66d90f24060f56/include/linux/elfcore.h#L73-L74 QEMU has a matching one: https://github.com/qemu/qemu/blob/19361471b59441cd6f2aa22d4fbee7a6e9e76586/linux-user/elfload.c#L3558-L3559 Here's the bug: File first examines `pr_psargs` via its offsets lists: https://github.com/file/file/blob/f042050f59bfc037677871c4d1037c33273f5213/src/readelf.c#L266-L267 If it finds a valid string there, it then checks the `pr_fname` buffer (immediately before in memory) if it contains only printable characters. If it does, it concludes that both buffers are the first and second parts of the same string, and prints output with them concatenated. See https://github.com/file/file/blob/f042050f59bfc037677871c4d1037c33273f5213/src/readelf.c#L894-L905 Strictly speaking, this is not sound because the `pr_fname` buffer is not guaranteed to be NULL terminated (i.e. have a non-printable character). In practice, this bug does not manifest for most coredumps because they are generated by the Linux kernel, which happens to NULL terminate `pr_fname`. This causes the above printable character check to fail, and only the `pr_psargs` buffer is output. Environment: ``` # file --version file-5.38 magic file from /etc/magic:/usr/share/misc/magic # lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 20.04.4 LTS Release: 20.04 Codename: focal # uname -a Linux 489a926e3c6b 5.10.104-linuxkit 0000001 SMP Thu Mar 17 17:08:06 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux ```
Tags:
Steps To Reproduce:	For convenience I've attached a QEMU coredump and native Linux coredump. They exceed the upload limit, so I've made them available here: https://www.dropbox.com/sh/2si8tcbt2w5rumh/AAB447Q2Vey6kgSozQV5uKa6a?dl=0 # file * native-linux-core.core: ELF 64-bit LSB core file, x86-64, version 1 (SYSV), SVR4-style, from './main-more-than-sixteen-chars', real uid: 0, effective uid: 0, real gid: 0, effective gid: 0, execfn: './main-more-than-sixteen-chars', platform: 'x86_64' qemu_main-test-this-is-more-than-sixteen-chars_20220705-161944_20938.core: ELF 64-bit LSB core file, x86-64, version 1 (SYSV), SVR4-style, from 'main-test-this-i', real uid: 0, effective uid: 0, real gid: 0, effective gid: 0, platform: 'i686' To try from scratch: - Build an x86_64 binary that segfaults and name it with a filename >= 16 bytes in length int main(){         *(int*)(0) = 0; } gcc -o main-more-than-sixteen-chars main.c - Install qemu-user (e.g. apt install qemu-user) - Enable coredumps (ulimit -c unlimited) - Run the binary under qemu-x86_64 (e.g. qemu-x86_64 main-more-than-sixteen-chars) - Run file on the coredump (e.g. file core)
Additional Information:
Attached Files:

Notes
(0003783) mam-ableton    2022-07-05 14:26	> - Run file on the coredump (e.g. file core) Typo here; the coredump will not be named "core''. It will begin with "qemu_..."
(0003784) christos    2022-07-07 15:32	Hmm the native hexdump looks like: 000006e0 be 51 00 00 01 00 00 00 6d 61 69 6e 2d 6d 6f 72 |.Q......main-mor| 000006f0 65 2d 74 68 61 6e 2d 00 2e 2f 6d 61 69 6e 2d 6d |e-than-../main-m| 00000700 6f 72 65 2d 74 68 61 6e 2d 73 69 78 74 65 65 6e |ore-than-sixteen| 00000710 2d 63 68 61 72 73 20 00 00 00 00 00 00 00 00 00 |-chars .........| We first look at the full name at 0x6f8, we find it and we print it. Where the qemu one looks like: 00000590 ca 51 00 00 01 00 00 00 6d 61 69 6e 2d 74 65 73 |.Q......main-tes| 000005a0 74 2d 74 68 69 73 2d 69 d7 58 80 01 40 20 20 20 |t-this-i.X..@ | 000005b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000005f0 00 00 00 00 00 00 00 00 05 00 00 00 10 01 00 00 |................| 00000600 06 00 00 00 43 4f 52 45 00 75 6e 61 03 00 00 00 |....CORE.una....| As you can see QEMU does not put the full command line where we expect it (at 0x5a8 byte 0xd7) and the contents there are non printable, so it tries at 0x598 and prints the short name (which is as you mention non-nul-terminated).
(0003785) mam-ableton    2022-07-07 16:01	Thanks for the quick reply. My mistake - that qemu core dump was from a buggy old qemu version which produced buggy coredumps. (See https://github.com/qemu/qemu/commit/5f779a3a26a9dcc8072d909b7759bb9fade097a9) I have supplied a coredump from a newer qemu version : "qemu_main-test-this-is-more-than-sixteen-chars_20220702-121202_14541.core" in the same link: https://www.dropbox.com/sh/2si8tcbt2w5rumh/AAB447Q2Vey6kgSozQV5uKa6a?dl=0 That produces output like this: qemu_main-test-this-is-more-than-sixteen-chars_20220702-121202_14541.core: ELF 64-bit LSB core file, x86-64, version 1 (SYSV), SVR4-style, from 'main-test-this-i./main-test-this-is-more-than-sixteen-chars', real uid: 0, effective uid: 0, real gid: 0, effective gid: 0, execfn: './main-test-this-is-more-than-sixteen-chars', platform: 'x86_64' In this case the short name and arguments are directly continuous. First it will look at the args, but then it will peek at the short name immediately before, see that there are all printable characters, and assume they are both part of the same string, which is not the case. 000005f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000600: 0000 0000 0500 0000 8800 0000 0300 0000 ................ 00000610: 434f 5245 0075 6e61 0000 0000 0000 0000 CORE.una........ 00000620: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000630: cd38 0000 ad38 0000 cd38 0000 ad38 0000 .8...8...8...8.. 00000640: 6d61 696e 2d74 6573 742d 7468 6973 2d69 main-test-this-i 00000650: 2e2f 6d61 696e 2d74 6573 742d 7468 6973 ./main-test-this 00000660: 2d69 732d 6d6f 7265 2d74 6861 6e2d 7369 -is-more-than-si 00000670: 7874 6565 6e2d 6368 6172 7320 0000 0000 xteen-chars .... 00000680: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000690: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000006a0: 0500 0000 2001 0000 0600 0000 434f 5245 .... .......CORE 000006b0: 0075 6e61 0300 0000 0000 0000 4000 0000 .una........@...
(0003786) christos    2022-07-07 17:20	Thanks, fixed.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
359	[file] General	minor	always	2022-06-14 17:02	2022-07-04 20:08
Reporter:	darose	Platform:
Assigned To:	christos	OS:	Linux
Priority:	normal	OS Version:	5.18.3
Status:	resolved	Product Version:	5.42
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.43
		Target Version:
Summary:	v5.42 not correctly identifying JSON Lines files
Description:	v5.41 would correctly identify a JSON Lines file (see https://jsonlines.org/ and http://ndjson.org/) as json. v5.42 now only identifies it as ascii text. (This is breaking functionality in a project of mine which requires the ability to detect json files.)
Tags:
Steps To Reproduce:	1. Upgrade "file" to v5.42 2. Run "file" on a valid JSON Lines file. 3. "file" will not identify it as json; only ascii text.
Additional Information:	See the following output for an example: $ cat /tmp/test.json {} {} $ pacman -Q file file 5.41-1 $ file /tmp/test.json /tmp/test.json: JSON data $ sudo pacman -S file ... Packages (1) file-5.42-1 ... $ pacman -Q file file 5.42-1 $ file /tmp/test.json /tmp/test.json: ASCII text
Attached Files:

Notes
(0003781) christos    2022-07-04 20:08	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
362	[file] General	major	always	2022-06-25 14:43	2022-07-04 19:45
Reporter:	ro-ee	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.42
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.43
		Target Version:
Summary:	File name in output shortened with -raw option
Description:	With recent PR/351: CathyKMeow: octalify unprintable characters in filenames unless raw, a regression has been introduced that has ramifications for Midnight Commander (mc). MC doesn’t use the -raw option, and does not expect the octal version of the file name in the output. This is not the issue, though. With the -raw option, the output is shortened. It looks like the file name in the output is shortened to /n/ Bytes where /n/ is the number of Characters, not Bytes. Example: Testö.jpg = 9 characters, but 10 Bytes (because ö requires 2 bytes). File then outputs testö.jp , which is a string of 9 byte length
Tags:
Steps To Reproduce:	Have a file with one or more characters ≥ U+0080, e.g. ä ö ü Χ Л هل file -r <filename> will output the filename shorted file äöü -r ä�: empty
Additional Information:	I noticed different behavior when using shell globbing. file -r * in a directory with äöü will output äöü correctly, but will shorten Χαίρετε to Χαίρετ , Здравствуйте to Здравс
Attached Files:	image.png (3,142 bytes) 2022-06-25 14:43 https://bugs.astron.com/file_download.php?file_id=282&type=bug

Notes
(0003766) ro-ee    2022-06-25 18:03	Thinking about it... "PR/351: CathyKMeow: octalify unprintable characters in filenames unless raw" why are characters ≥ U+0080 even considererd unprintable? The change was originally introduced because of some issues with control characters < U+0020 (especially \n), see Bug 351.
(0003767) dimich    2022-06-28 03:05	Bug 351 is closed and i can't comment there, so commen here. 1) `ls` and `find` replace non-printable characters only if stdout is a tty. There are no character replacement for piped output: ``` $ mkdir a$'\n'b $ ls | cat a b $ find . | cat . ./a b ``` 2) Characters above 0x80 aren't non-printable.
(0003768) ro-ee    2022-06-28 08:53	Hm, the changes from bug 351 lead to Midnight commander not properly detecting images with umlauts etc. in the file name. See https://www.midnight-commander.org/ticket/4377 I find it strange that midnight commander would not use piped output, so in theory the change should not even have any effect. without the -r option, all characters above 0x80 get octalified. alex@horus:~> file testö.jpg test\303\266.jp: JPEG image data, JFIF standard 1.01, resolution (DPCM), density 118x118, segment length 16, progressive, precision 8, 1706x1132, components 3
(0003769) dimich    2022-06-28 09:15	> I find it strange that midnight commander would not use piped output, so in theory the change should not even have any effect. Yep, two overlapped issues together lead to the bug. First, `file` utility corrupts filenames. Second, `mc` relays on filename from file's output. First one can be fixed by checking isatty(STDOUT_FILENO) as other tools do. Second one can be fixed by removing filename from output with --brief option (or even using libmagic directly). But i can't understand why after all non-ascii characters are considered as non-printable.
(0003770) dimich    2022-06-28 09:44	Sorry ro-ee, maybe i misunderstood your previous comment. I know about mc bug and commented there also. I was going to create a ticket for `file` here but you made it first. Fix for "bug 351" is implemented incorrectly. I'd take CathyKMeow's attention but can't comment or reopen ticket 351. This issue affects not only mc but any other software which invokes `file` and reads filename, also it confuses users.
(0003779) christos    2022-07-04 19:45	Try it now.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
361	[file] General	feature	always	2022-06-22 22:12	2022-07-04 17:15
Reporter:	wof	Platform:
Assigned To:	christos	OS:
Priority:	low	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.43
		Target Version:
Summary:	add save file detection of burp
Description:	BurpSuite is a HTTP man-in-the-middle-proxy used for penetration tests. At the moment save files are not detected. I've attached my first patch to file.
Tags:
Steps To Reproduce:	% file 2022-06-23-test.burp 2022-06-23-test.burp: data
Additional Information:
Attached Files:	burp.magic.patch (858 bytes) 2022-06-22 22:12 https://bugs.astron.com/file_download.php?file_id=280&type=bug 2022-06-23-test.burp (524,288 bytes) 2022-06-22 22:12 https://bugs.astron.com/file_download.php?file_id=281&type=bug

Notes
(0003778) christos    2022-07-04 17:15	committed, thanks

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
360	[file] General	major	have not tried	2022-06-14 22:21	2022-07-04 17:12
Reporter:	kloczek	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.42
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.43
		Target Version:
Summary:	"file -N -f" print dot instead file name
Description:	Just found that after upgrade I'm not able to build any rpm package because "file -N -f" prints in filst column of the output instead file name just ".".
Tags:
Steps To Reproduce:	Example [tkloczko@devel-g2v SPECS]$ find /home/tkloczko/rpmbuild/BUILDROOT/libusb-1.0.26-2.fc35.x86_64/ '!' -path '/home/tkloczko/rpmbuild/BUILDROOT/libusb-1.0.26-2.fc35.x86_64//usr/lib/debug/*.debug' -type f '(' -perm -0100 -or -perm -0010 -or -perm -0001 ')' -print /home/tkloczko/rpmbuild/BUILDROOT/libusb-1.0.26-2.fc35.x86_64/usr/lib64/libusb-1.0.so.0.3.0 /home/tkloczko/rpmbuild/BUILDROOT/libusb-1.0.26-2.fc35.x86_64/usr/lib64/libusb-1.0.la [tkloczko@devel-g2v SPECS]$ find /home/tkloczko/rpmbuild/BUILDROOT/libusb-1.0.26-2.fc35.x86_64/ '!' -path '/home/tkloczko/rpmbuild/BUILDROOT/libusb-1.0.26-2.fc35.x86_64//usr/lib/debug/*.debug' -type f '(' -perm -0100 -or -perm -0010 -or -perm -0001 ')' -print |file -N -f - /: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=5dc726ff611aee897cb801d30ac1927f0434a46e, with debug_info, not stripped, too many notes (256) /: libtool library file, ASCII text [tkloczko@devel-g2v SPECS]$ file --version file-5.42 magic file from /etc/magic:/usr/share/misc/magic The same after downgrade to prev version [tkloczko@devel-g2v SPECS]$ find /home/tkloczko/rpmbuild/BUILDROOT/libusb-1.0.26-2.fc35.x86_64/ '!' -path '/home/tkloczko/rpmbuild/BUILDROOT/libusb-1.0.26-2.fc35.x86_64//usr/lib/debug/*.debug' -type f '(' -perm -0100 -or -perm -0010 -or -perm -0001 ')' -print |file -N -f - /home/tkloczko/rpmbuild/BUILDROOT/libusb-1.0.26-2.fc35.x86_64/usr/lib64/libusb-1.0.so.0.3.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=5dc726ff611aee897cb801d30ac1927f0434a46e, with debug_info, not stripped, too many notes (256) /home/tkloczko/rpmbuild/BUILDROOT/libusb-1.0.26-2.fc35.x86_64/usr/lib64/libusb-1.0.la: libtool library file, ASCII text [tkloczko@devel-g2v SPECS]$ file --version file-5.41 magic file from /etc/magic:/usr/share/misc/magic
Additional Information:	I've not changed anything except version between those two version in my build prcedure. Part of my spec file which is building file package %build autoreconf -fiv %configure \         --disable-libseccomp \         --disable-rpath \         --disable-static \         --enable-fsect-man5 \         %{nil} %make_build
Attached Files:

Notes
(0003765) kloczek    2022-06-16 22:19	Looks like Fedora rolled back as well. https://bugzilla.redhat.com/show_bug.cgi?id=2095871
(0003777) christos    2022-07-04 17:12	Dup of PR/358

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
358	[file] General	major	always	2022-06-12 21:48	2022-07-04 17:01
Reporter:	jpalus	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.42
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.43
		Target Version:
Summary:	filenames in output limited to single char when reading files from stdin (5.42 regression)
Description:	When reading files from stdin file 5.42 cuts filename in output to single char (see "c" instead of whole "configure.ac"): ``` $ echo configure.ac|./src/file -m magic/magic.mgc -f - c: M4 macro processor script, ASCII text ``` Appears to be regression introduced by: https://github.com/file/file/commit/f448f3e5c37de8c285ac14b032b2bdcea82fc08b where `inname` is now passed to `file_printable` before printing, however last parameter `wid`, that should be length on `inname` is always `1` for input from stdin.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	file-5.42-fix-size-of-lines-read-from-stdin.patch (689 bytes) 2022-06-14 12:56 https://bugs.astron.com/file_download.php?file_id=279&type=bug

Notes
(0003764) bero    2022-06-14 12:56	The problem is that stdin can't be rewound, therefore the check for the longest filename size doesn't work. The code is aware of this, but "fixes" it by hardcoding 1. The attached patch should fix it correctly.
(0003776) christos    2022-07-04 17:01	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
357	[file] General	feature	N/A	2022-06-12 05:32	2022-07-04 16:40
Reporter:	a@gitadora.top	Platform:	aarch64
Assigned To:	christos	OS:	Debian
Priority:	normal	OS Version:	11
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.43
		Target Version:
Summary:	Please add EROFS loop file detection
Description:	Please add EROFS loop file detection,it's relatively new file system format.
Tags:	magic
Steps To Reproduce:	1.Got a EROFS file(i.e. system_a.bin) 2.Using file to test it $file system_a.bin system_a.bin: data 3.Test mount it $sudo mount ./system_a.bin /media $sudo df -Th /media Filesystem Type Size Used Avail Use% Mounted on /dev/loop0 erofs 3.7G 3.7G 0 100% /media
Additional Information:
Attached Files:

Notes
(0003762) polluks    2022-06-12 18:42	#define EROFS_SUPER_MAGIC_V1 0xE0F5E1E2 https://kernel.googlesource.com/pub/scm/linux/kernel/git/xiang/erofs-utils/+/refs/heads/experimental/include/erofs_fs.h#12
(0003775) christos    2022-07-04 16:40	Added!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
356	[file] General	minor	always	2022-06-11 11:42	2022-07-04 16:18
Reporter:	davewhite	Platform:	Linux
Assigned To:	christos	OS:	Ubuntu
Priority:	normal	OS Version:	20.04
Status:	resolved	Product Version:	5.42
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.43
		Target Version:
Summary:	JSON parsing incorrectly accepts misspellings for true/false/null in json_parse_const()
Description:	A JSON file containing the structure {"test":true} Is detected as 'JSON data'. The text {"test":txxx} Is also considered valid JSON. During parsing, when detecting 't' (in file is_json.c:374) the json_parse_const() is called with the value "true". json_parse_const() verifies the text found matches the expected constant, but does nothing with the result of the test, and always returns true as long as the first letter matches (t for true, f for false or n for null) and the word found was the correct length. Hence {"test":nxx} is invalid, while {"test":nxxx} is valid json.
Tags:	json
Steps To Reproduce:	$ echo '{"test":txxx}' > file.json $ file file.json file.json: JSON data
Additional Information:	Issue exists when built from latest source.
Attached Files:

Notes
(0003761) davewhite    2022-06-11 11:45	The following batch resolves the issue diff --git src/is_json.c src/is_json.c index 86def31..8053d4f 100644 --- src/is_json.c +++ src/is_json.c @@ -327,6 +327,7 @@ json_parse_const(const unsigned char **ucp, const unsigned char *ue,     for (len--; uc < ue && --len;) {         if (*uc++ == *++str)             continue; + break     }     if (len)         DPRINTF("Bad const: ", uc, *ucp);
(0003774) christos    2022-07-04 16:18	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
351	[file] General	feature	always	2022-05-27 23:50	2022-06-28 04:03
Reporter:	CathyKMeow	Platform:	GNU/Linux
Assigned To:	christos	OS:	Arch Linux ARM
Priority:	none	OS Version:	Rolling
Status:	resolved	Product Version:	5.41
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.42
		Target Version:
Summary:	Escape "special" characters before outputting
Description:	`file` does not escape "special" characters in file name before outputting. This is vulnerable to Trojan Source attacks. (See https://trojansource.codes) Example: An attacker make an executable binary file containing malicious code look like a non-executable ASCII text file, so the user might try to open them in the GUI by double clicking on it, which instead executes the file. Expected behavior: ``` user@localhost:~$ mkdir $'a\nb' user@localhost:~$ file $'a\nb' 'a'$'\n''b': directory ``` What I see instead: ``` user@localhost:~$ mkdir $'a\nb' user@localhost:~$ file $'a\nb' a b: directory ```
Tags:
Steps To Reproduce:	``` $ mkdir $'a\nb' $ file $'a\nb' ```
Additional Information:	``` user@localhost:~/file_bug_test$ mkdir $'a\nb' mkdir: cannot create directory 'a\nb': File exists user@localhost:~/file_bug_test$ ls 'a'$'\n''b' user@localhost:~/file_bug_test$ find . . ./a?b user@localhost:~/file_bug_test$ tar -cf file_bug_test.tar * user@localhost:~/file_bug_test$ tar --list -f file_bug_test.tar a\nb/ user@localhost:~/file_bug_test$ ```
Attached Files:

Notes
(0003753) christos    2022-05-28 01:06	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
354	[file] General	minor	always	2022-06-06 21:37	2022-06-10 14:14
Reporter:	vinc17	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.41
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.43
		Target Version:
Summary:	Fails to detect JSON in case of empty array with spaces
Description:	When a JSON file has an empty array with spaces between the brackets, it is misdetected as a text file.
Tags:
Steps To Reproduce:	$ echo '{"a":[ ]}' | file - /dev/stdin: ASCII text
Additional Information:	This is due to a missing call to json_skip_space in function json_parse_array of src/is_json.c (see json_parse_object as a comparison). I've attached a patch with a testcase.
Attached Files:	file-json-array.patch (1,189 bytes) 2022-06-06 21:37 https://bugs.astron.com/file_download.php?file_id=277&type=bug

Notes
(0003760) christos    2022-06-10 14:14	Committed, many thanks (and for providing the test case!).

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
355	[file] General	minor	always	2022-06-08 18:35	2022-06-10 14:10
Reporter:	hridoy31	Platform:	Linux
Assigned To:	christos	OS:	Debian
Priority:	normal	OS Version:	11.3
Status:	feedback	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	multiple definition of `handle_interrupt'
Description:	When compiling tcsh according to the BUILDING file, at step 8, after run make, the make gives back error about multiple definition of `handle_interrupt', with the following line: /usr/bin/ld: tc.sig.o:/home/hridoy/tcsh/tc.sig.c:59: multiple definition of `handle_interrupt'; sh.o:/home/hridoy/tcsh/sh.h:569: first defined here
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	Screenshot from 2022-06-09 00-34-26.png (31,149 bytes) 2022-06-08 18:35 https://bugs.astron.com/file_download.php?file_id=278&type=bug

Notes
(0003758) christos    2022-06-10 14:10	Should be fixed in HEAD.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
352	[tcsh] General	minor	always	2022-05-30 05:56	2022-06-05 10:01
Reporter:	zjs	Platform:	AMD64
Assigned To:		OS:	FreeBSD
Priority:	normal	OS Version:	13.1-RELEASE
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	tcsh does not display emoji
Description:	Hi there, I have run FreeBSD 13.1 RELEASE. I have a Chinese input method, which could input emoji. The problem is when I input an emoji, for example: 🥰 after the tcsh prompt, it displayed as: ``` zjs@freebsd:~ % \U+1F970 🥰: Command not found. ``` The tcsh could display some emoji, for example: ❤️️. The version of the tcsh is: tcsh 6.22.04 (Astron) 2021-04-26 I have run into the same problem on Debian with tcsh version 6.21.00 (Astron) 2019-05-08. Best, Jinsong
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003757) polluks    2022-06-05 10:01	Indeed, Unicode's SMP support is missing. Here comes a quick macOS check: bash ok dash ok fish ok ksh ok tcsh fails zsh fails

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
345	[file] General	minor	always	2022-05-12 18:20	2022-06-01 12:05
Reporter:	Almalixia	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	feedback	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	mime_content_type result gets duplicated for xlsx
Description:	When calling mime_content_type() on a file of type xlsx, it's returning 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheetapplication/vnd.openxmlformats-officedocument.spreadsheetml.sheet'.
Tags:
Steps To Reproduce:	echo mime_content_type('file_name.xlsx');
Additional Information:
Attached Files:

Notes
(0003745) christos    2022-05-21 22:30	I don't maintain the php bindings for libmagic; I just tried it on my machine and it works: [6:09pm] 370>php <?php echo mime_content_type('foo.xlsx') . "\n"; application/vnd.openxmlformats-officedocument.spreadsheetml.sheet [6:10pm] 371>php -v PHP 7.4.27 (cli) (built: Apr 25 2022 13:02:57) ( NTS ) Copyright (c) The PHP Group Zend Engine v3.4.0, Copyright (c) Zend Technologies
(0003749) jeremysawesome    2022-05-26 22:44	Performed similar steps on my machine: ``` [jdev@dev-01 ~]$ php -r 'echo mime_content_type("Foo.xlsx")."\n";' application/vnd.openxmlformats-officedocument.spreadsheetml.sheetapplication/vnd.openxmlformats-officedocument.spreadsheetml.sheet [jdev@dev-01 ~]$ php -v PHP 7.4.28 (cli) (built: Feb 15 2022 13:23:10) ( NTS ) Copyright (c) The PHP Group Zend Engine v3.4.0, Copyright (c) Zend Technologies     with Zend OPcache v7.4.28, Copyright (c), by Zend Technologies     with Xdebug v2.9.6, Copyright (c) 2002-2020, by Derick Rethans ``` @christos - is this the expected output? And, is this the correct place to report these errors? If this is not the correct place to report these errors, where would the correct place be? Thanks!
(0003756) christos    2022-06-01 12:05	I think that the PHP bug tracker would be a more appropriate place.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
348	[file] General	minor	always	2022-05-24 06:14	2022-05-31 18:54
Reporter:	frokaikan	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.42
		Target Version:
Summary:	Can the "-m" parameter take anything as its value?
Description:	`./file -m ./bad_magic ./file` The file `bad_magic` was attached. Then the program throws SIGABRT.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	bad_magic (1,378 bytes) 2022-05-24 06:14 https://bugs.astron.com/file_download.php?file_id=276&type=bug

Notes
(0003755) christos    2022-05-31 18:54	Add missing switch cases.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
349	[file] General	minor	always	2022-05-24 06:24	2022-05-31 18:41
Reporter:	Farknay	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.41
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.42
		Target Version:
Summary:	Any text file content starting with PR is detected as RAGE Package Format (RPF)
Description:	Since the addition of GTA file formats in the games magic file, any text file starting with the string PR is detected as RAGE Package Format (RPF). I've only been able to test this in Git Bash on windows, all the Linux boxes I work on are using older versions of file, and I'm not allowed to upgrade them.
Tags:
Steps To Reproduce:	echo 'PROMPT Hello' > sample.sql file sample.sql sample: RAGE Package Format (RPF),
Additional Information:
Attached Files:

Notes
(0003754) christos    2022-05-31 18:41	Made stronger.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
343	[file] General	feature	have not tried	2022-05-09 20:56	2022-05-21 22:51
Reporter:	jstein	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.42
		Target Version:
Summary:	btrfs send image (new file format)
Description:	btrfs send can dump a filesystem in a structured file system image file. This file can be imported by btrfs receive. The dump starts with btrfs-stream
Tags:
Steps To Reproduce:
Additional Information:	see also https://btrfs.wiki.kernel.org/index.php/Design_notes_on_Send/Receive
Attached Files:

Notes
(0003747) christos    2022-05-21 22:51	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
344	[file] General	major	always	2022-05-11 06:13	2022-05-21 22:47
Reporter:	rven	Platform:
Assigned To:	christos	OS:
Priority:	high	OS Version:	Ubuntu 20.04.4 L
Status:	feedback	Product Version:	5.41
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	image/svg+xml not correctly guessed from buffer
Description:	When a svg needs to be parsed with the from_buffer method, it returns an incorrect mimetype when the <?xml version='1.0' encoding='UTF-8' ?> tag is included on top of the xml declaration
Tags:
Steps To Reproduce:	import magic a = b"<svg height='180' width='180' xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink'><rect fill='hsl(349, 60%, 45%)' height='180' width='180'/><text fill='#ffffff' font-size='96' text-anchor='middle' x='90' y='125' font-family='sans-serif'>M</text></svg>" magic.from_buffer(a, mime=True) => 'image/svg+xml' import magic a = b"<?xml version='1.0' encoding='UTF-8' ?><svg height='180' width='180' xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink'><rect fill='hsl(349, 60%, 45%)' height='180' width='180'/><text fill='#ffffff' font-size='96' text-anchor='middle' x='90' y='125' font-family='sans-serif'>M</text></svg>" magic.from_buffer(a, mime=True) => 'text/xml'
Additional Information:
Attached Files:

Notes
(0003746) christos    2022-05-21 22:47	should be fixed in HEAD.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
346	[file] General	minor	always	2022-05-13 12:09	2022-05-20 11:12
Reporter:	jukuisma	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	feedback	Product Version:	5.41
Product Build:		Resolution:	reopened
Projection:	none
ETA:	none	Fixed in Version:	5.42
		Target Version:
Summary:	Incorrect video/dv mimetype
Description:	`file` identifies DV files correctly, but returns `application/octet-stream` as the mimetype. No mimetype has been defined for DV files: https://github.com/file/file/blob/22209154702032e9b7f2e96eb7eab174f8e87af9/magic/Magdir/animation#L944.
Tags:
Steps To Reproduce:	$ wget https://github.com/Digital-Preservation-Finland/file-scraper/raw/c9facae6df774544e4ef8f7a039a926796ef57b8/tests/data/video_dv/valid__pal_lossy.dv $ file valid__pal_lossy.dv $ file --mime-type valid__pal_lossy.dv
Additional Information:	https://www.iana.org/assignments/media-types/video/DV
Attached Files:

Notes
(0003743) christos    2022-05-14 22:06	Fixed, thanks
(0003744) jukuisma    2022-05-20 11:12	Shouldn't this be "video/DV" or "video/dv" instead of "video/x-dv"? MIME type "video/DV" is registered in IANA, see the RFC of the registration: https://www.rfc-editor.org/rfc/rfc6469.html As we understand, MIME types with "x-" prefix should be avoided: https://www.rfc-editor.org/rfc/rfc6838.html#section-3.4 (last paragraph of section 3.4) which refers to: https://www.rfc-editor.org/rfc/rfc6648.html

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
347	[file] General	feature	N/A	2022-05-14 18:04	2022-05-14 20:36
Reporter:	GerbilSoft	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.42
		Target Version:
Summary:	Detect Godot textures; improvements for NGPC, Mega Drive, others
Description:	The attached patches add the following: * Detect Godot STEX textures from Godot 3 and Godot 4. This includes image size, codec, and rescale value (if applicable). * Neo Geo Pocket Color: Print the NEOPxxxx serial number. * riff: Print calling metadata from RecorderGear TR500 call recordings. The metadata indicates if it was an incoming or outgoing call, and the dialed/received phone number. * DDS: Print DXGI formats. * Mega Drive: Improve system type detection; add more variants for Sega Pico, including a few that don't start with "SEGA". * c64: Expand CBM cartridge image detection for VICE 3.0, which now includes C128, CBM-II, VIC-20, and Plus/4.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	file.2022-05-14.ngpc.TR500.DXGI.godot.c64-cart.tar.gz (9,486 bytes) 2022-05-14 18:04 https://bugs.astron.com/file_download.php?file_id=275&type=bug

Notes
(0003742) christos    2022-05-14 20:36	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
341	[file] General	minor	have not tried	2022-04-23 11:00	2022-04-25 17:34
Reporter:	blacktav	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	feedback	Product Version:	5.41
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	"file -z" breaks on zipped files with "Bad system call"
Description:	When testing a zip archive, "file" breaks reporting "Bad system call" Testing a dump from Google Photos $ file Photos-001.zip Photos-001.zip: Zip archive data, at least v2.0 to extract, compression method=deflate $ file -z Photos-001.zip Photos-001.zip: Bad system call Testing a zip archive $ file mc-test-pass.zip mc-test-pass.zip: Zip archive data, at least v1.0 to extract, compression method=store $ file -z mc-test-pass.zip mc-test-pass.zip: Bad system call OS is ArchLinux
Tags:
Steps To Reproduce:	1. download a bundle from Google Photos 2. test download with "file -z <filename>" or 1. create an archive using zip (Zip 3.0 (July 5th 2008), by Info-ZIP) 2. test download with "file -z <filename>"
Additional Information:	$ file --version file-5.41 magic file from /usr/share/file/misc/magic seccomp support included
Attached Files:	mc-test-pass.zip (16,836 bytes) 2022-04-23 11:00 https://bugs.astron.com/file_download.php?file_id=274&type=bug

Notes
(0003736) blacktav    2022-04-23 11:10	Sorry, inappropriate report Solution being to use -S switch as in "file -S -z <filename>" Maybe the error response could be more useful though
(0003741) christos    2022-04-25 17:34	Yes, we could install a bad system call handler, but it is ugly. I prefer to leave it as is.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
340	[file] General	minor	always	2022-04-12 20:47	2022-04-25 17:33
Reporter:	ESultanik	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.41
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.42
		Target Version:
Summary:	The ASF_JFIF_Media guid definition is missing two bytes
Description:	Line 91 of `magic/Magdir/asf` contains this GUID: `B61BE100-5B4E-11CF-A8FD-00805F5C44`. That GUID is missing its last two bytes. I believe it should actually be `B61BE100-5B4E-11CF-A8FD-00805F5C442B`. https://github.com/file/file/blob/961e193e4519d40983322ed853cea6511d4b6494/magic/Magdir/asf#L91
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003740) christos    2022-04-25 17:33	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
339	[file] General	feature	always	2022-04-10 14:53	2022-04-25 17:31
Reporter:	jmaynard	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.42
		Target Version:
Summary:	Add more Hercules DASD image types
Description:	The attached .magic file can be used to replace lines 1696-1711 of magic/Magdir/images . It adds recognition of CKD64/CCKD64 DASD, and for compressed DASD, it will report the number of cylinders on the volume and the compression algorithm.
Tags:	magic
Steps To Reproduce:
Additional Information:
Attached Files:	.magic (1,942 bytes) 2022-04-10 14:53 https://bugs.astron.com/file_download.php?file_id=273&type=bug

Notes
(0003739) christos    2022-04-25 17:31	Replaced, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
338	[file] General	feature	N/A	2022-04-09 09:15	2022-04-25 17:28
Reporter:	polluks	Platform:	MacBook Pro
Assigned To:	christos	OS:	macOS
Priority:	normal	OS Version:	12.3
Status:	resolved	Product Version:	5.41
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.42
		Target Version:
Summary:	Added more Oric
Description:	diff --git a/magic/Magdir/oric b/magic/Magdir/oric index 79e264ea..678ba770 100644 --- a/magic/Magdir/oric +++ b/magic/Magdir/oric @@ -5,8 +5,12 @@  # From: Stefan A. Haubenthal <polluks@sdf.lonestar.org>  # References:  # http://fileformats.archiveteam.org/wiki/TAP_(Oric) +# http://fileformats.archiveteam.org/wiki/DSK_(Oric)  0 string \x16\x16\x16\x24 Oric tape,  >6 byte =0x00 BASIC,  >6 byte =0x80 memory block,  >7 byte >0x00 autorun,  >13 string x "%.15s" + +0 string ORICDISK Oric Image +0 string MFM_DISK Oric Image
Tags:	magic
Steps To Reproduce:
Additional Information:
System Description	Apple M1
Attached Files:

Notes
(0003738) christos    2022-04-25 17:28	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
342	[file] General	minor	always	2022-04-25 06:34	2022-04-25 06:34
Reporter:	jayvdb	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:	5.41
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	jar files with POSIX shell script header do not mention they are JAR files
Description:	https://github.com/pinterest/ktlint/releases/download/0.45.2/ktlint is an example of a JAR file with a POSIX shell script header, which looks like --- #!/bin/sh JV=$(java -version 2>&1 | head -1 | cut -d'"' -f2 | sed '/^1\./s///' | cut -d'.' -f1) X=$( [ "$JV" -ge "16" ] && echo "--add-opens java.base/java.lang=ALL-UNNAMED" || echo "") exec java $X -Xmx512m -jar "$0" "$@" PK... ``` The java executable can run it as a jar file directly. i.e. the following prints the help on all platforms java -jar /path/to/ktlint --help The file command says it is "POSIX shell script executable (binary data)" When I manually remove the script header, file then reports it as "Zip archive data, at least v1.0 to extract, compression method=deflate" It would be great if it could mention that it is a JAR or ZIP file, perhaps like "POSIX shell script executable (JAR ..)" or "POSIX shell script executable (Zip archive data, ...)"
Tags:
Steps To Reproduce:	1. Download https://github.com/pinterest/ktlint/releases/download/0.45.2/ktlint 2. `file ktlint`
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
282	[tcsh] General	minor	always	2021-08-15 13:51	2022-04-23 12:21
Reporter:	kato	Platform:	GNU/Linux x86_64
Assigned To:	christos	OS:	Open SuSE Leap
Priority:	normal	OS Version:	15.3
Status:	confirmed	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	tcsh 6.20.00 : shell variable "anyerror" does not work as described in the tcsh man page
Description:	If "anyerror" is set, the exit status of a non-simple command should be non-zero if any subcommand fails. However, this does not hold in any case.
Tags:
Steps To Reproduce:	/home/test> tcsh --version tcsh 6.20.00 (Astron) 2016-11-24 (x86_64-unknown-linux) options wide,nls,lf,dl,al,kan,sm,color,filec /home/test> cat non-existent-file|cat cat: non-existent-file: No such file or directory Exit 1 /home/test> set variable=`cat non-existent-file` cat: non-existent-file: No such file or directory Exit 1 /home/test> set variable=`cat non-existent-file|cat` cat: non-existent-file: No such file or directory /home/test> echo $? 0
Additional Information:
Attached Files:

Notes
(0003676) christos    2021-11-14 17:35	set x=`cat /does/not/exist` should set status to 1 and does not.
(0003737) kato    2022-04-23 12:21	The bug persists with tcsh 6.24.00 with Open SuSE Leap 15.3: /home/test> echo $version tcsh 6.24.00 (Astron) 2022-02-02 (x86_64-suse-linux-suse-linux) options wide,nls,lf,dl,al,kan,sm,color,filec /home/test> set anyerror /home/test> set x=`cat /does/not/exist` cat: /does/not/exist: No such file or directory /home/test> echo $status 1 /home/test> set x=`cat /does/not/exist|less` cat: /does/not/exist: No such file or directory /home/test> echo $status 0

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
186	[file] General	minor	always	2020-08-24 02:14	2022-04-13 07:16
Reporter:	joveler	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	confirmed	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	Korean text file misidentified as 'COM executable for DOS'
Description:	[Summary] Some Korean text file encoded as EUC-KR (aka CP949 on Windows) is misidentified as 'COM executable for DOS'. Part of the COM signatures should be disabled to fix it. [Technical Detail] EUC-KR encodes 4% of Korean characters as 'B8xx' ('륫/B8A0' ~ '뫼/B8FE'). In libmagic, the simplest COM signature only checks for 0xB8 at offset 0. As a result, libmagic causes false positive on EUC-KR text which starts with some Korean characters. Windows notepad (prior to Windows 10 v19H1) used ANSI encoding as default. It means almost every text file produced in Korean Windows is encoded as EUC-KR. Therefore it is a critical issue on Korean text files, as much Korean text files are misidentified as executable. [Fix] To reduce the negative impact, I propose to disable the simplest COM file signature. I have attached the diff file.
Tags:
Steps To Reproduce:	Run file command with attached euckr_falsepositive.txt. $ file euckr_falsepositive.txt euckr_falsepositive.txt: COM executable for DOS $ file euckr_falsepositive.txt --mime-type euckr_falsepositive.txt: application/x-dosexec
Additional Information:
Attached Files:	euckr_falsepositive.txt (293 bytes) 2020-08-24 02:14 https://bugs.astron.com/file_download.php?file_id=154&type=bug 0001-Disable-simplest-COM-signature-to-avoid-FP.patch (1,869 bytes) 2020-08-24 02:14 https://bugs.astron.com/file_download.php?file_id=155&type=bug

Notes
(0003482) christos    2020-09-06 15:14	Patched, thanks!
(0003648) christos    2021-10-12 18:24	Will revert for now and revisit. Breaks too many com executables. Perhaps we can limit it on what follows b8?
(0003734) joveler    2022-04-13 06:54	> Perhaps we can limit it on what follows b8? I have tried, but it is impossible. In 8086 opcode, 0xB8 is 'MOV AX, [IMM]' command. Since the IMM is any arbitrary two bytes, we cannot limit the followings. - B8 0A 16 -> MOV AX, 0x16A0 - B8 40 00 -> MOV AX, 0x0040
(0003735) joveler    2022-04-13 07:16	Every Extended Unix Code charset, such as EUC-JP, shares the same address space as EUC-KR. (Bytes of 0xA0-0xFF range, except 0x80) Keeping 0xB8 COM signature may also cause problems in every EUC charset. One idea is the use text/binary detection on buffers since the EUC charset tries to avoid ASCII control characters. I do not know how libmagic's text detection works yet, isn't it involve code patching?

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
335	[file] General	feature	N/A	2022-04-01 15:09	2022-04-09 09:13
Reporter:	polluks	Platform:	MacBook Pro
Assigned To:	christos	OS:	macOS
Priority:	normal	OS Version:	12.3
Status:	assigned	Product Version:	5.41
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Added mib
Description:	magic for Management Information Base
Tags:	magic
Steps To Reproduce:
Additional Information:
System Description	Apple M1
Attached Files:	mib (213 bytes) 2022-04-01 15:09 https://bugs.astron.com/file_download.php?file_id=271&type=bug

Notes
(0003729) christos    2022-04-04 16:14	I have a feeling this will end up with too many false positives.
(0003732) polluks    2022-04-08 13:49	Indeed, it's a bit weak magic. See also https://datatracker.ietf.org/doc/html/rfc1213#section-6
(0003733) polluks    2022-04-09 09:13	How this assignment operator is pretty unique.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
332	[file] General	minor	always	2022-03-22 09:49	2022-04-04 17:48
Reporter:	vinc17	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.41
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.42
		Target Version:
Summary:	misdetects "[number] text" files as JSON data
Description:	Some non-JSON text files have a form like "[number] text". For instance, Xorg.0.log log files start with something like [ 48.187] X.Org X Server 1.21.1.3 where "[number]" is a timestamp. Because "[number]" looks like a JSON object, "file" detects such files as JSON data, even though the object is followed by garbage when interpreted as JSON.
Tags:
Steps To Reproduce:	$ echo "[1] foo" | file - /dev/stdin: JSON data
Additional Information:	I don't know whether this is related, but I can see in the src/is_json.c source: /*  * if JSON_COUNT != 0:  * count all the objects, require that we have the whole data file  * otherwise:  * stop if we find an object or an array  */ [...] #if JSON_COUNT         /* bail quickly if not counting */         if (lvl > 1 && (st[JSON_OBJECT] || st[JSON_ARRAYN]))                 return 1; #endif The "#if JSON_COUNT" and "bail quickly if not counting" comment seem contradictory (if JSON_COUNT != 0, then it is counting), so I'm wondering what is expected.
Attached Files:	PR332.patch (1,061 bytes) 2022-03-25 09:30 https://bugs.astron.com/file_download.php?file_id=269&type=bug

Notes
(0003721) vinc17    2022-03-22 09:59	See also commit 479e0995523c42b83a055781d27a0c651dc286e2, whose intent was to fix PR/69 (the same bug I had reported in the past).
(0003722) wgh    2022-03-25 03:51	PR/165 reported that some json files are recognized as ASCII text, so the conditions for json file recognition were relaxed, resulting in some files being mistakenly recognized as json again。 I think that should be the reason。
(0003723) vinc17    2022-03-25 08:58	Note that in PR/165, all the examples consisted in one JSON object, with no "garbage" following it. If rules are relaxed to allow very simple objects like some of the PR/165 examples, then garbage detection becomes important to avoid many false positives. Anyway, I suppose that the fix of PR/69 was wrong: the solution was not to discard simple JSON objects; instead, it should have detected garbage (i.e. any non-whitespace character) after a JSON object has been parsed. Examples with json_pp: $ echo '[]' | json_pp [] $ echo '[] ' | json_pp [] $ echo '[] 1' | json_pp garbage after JSON object, at character offset 4 (before "\n") at /usr/bin/json_pp line 59.
(0003724) vinc17    2022-03-25 09:16	I'm going to provide a very simple patch, with testcases.
(0003725) vinc17    2022-03-25 09:30	In json_parse for the end of the recursion (lvl == 0), return 0 (failure) if the end of the file has not been reached (whitespace has been skipped just before). Two testcases are provided: 1. A simple JSON array followed by whitespace (a newline character), which should be recognized as JSON data. 2. Ditto followed by a non-whitespace character (a digit); this is not a valid JSON file, thus should be recognized as ASCII text.
(0003726) vinc17    2022-03-25 11:01	FYI, I've also reported the bug in the Debian BTS and put a simplified patch there (no testcases, 2 lines of context removed) so that it can also be applied on the current Debian package: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008247
(0003731) christos    2022-04-04 17:48	Committed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
334	[file] General	major	always	2022-03-30 13:51	2022-04-04 16:46
Reporter:	jmp3r	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.41
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.42
		Target Version:
Summary:	Binary data files detected as Unicode text
Description:	After fixing this: https://bugs.astron.com/view.php?id=319 new bug appeared Now the inverse situation for some files: the encrypted binary files detected as text I used the latest sources (HEAD) from github
Tags:
Steps To Reproduce:	Scan files from attach with `file` version latest sources (HEAD) I attached only two files, but there are thousands of such files.
Additional Information:
Attached Files:	bin.zip (23,800 bytes) 2022-03-30 13:51 https://bugs.astron.com/file_download.php?file_id=270&type=bug

Notes
(0003730) christos    2022-04-04 16:46	Detect invalid UTF16 and surrogate pairs.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
336	[file] General	minor	always	2022-04-04 08:29	2022-04-04 16:13
Reporter:	stefanwascoding	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.41
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.42
		Target Version:
Summary:	using `env` breaks detection of zsh scripts (shown as plain text)
Description:	Scripts using `#!/usr/bin/env zsh` as shebang are detected as text/plain mime type. Both default detection as well as using "--mime" are broken; `#!/usr/bin/zsh` shows up as "Paul Falstad's zsh script text executable" & "text/x-shellscript", env version shows up as "a /usr/bin/env zsh script text executable" or "text/plain". Works as expected when using bash in place of zsh. This might be a regression of https://bugs.astron.com/view.php?id=114
Tags:
Steps To Reproduce:	echo '#!/usr/bin/env zsh' > myzshscript && chmod +x myzshscript && file --mime-type myzshscript
Additional Information:
Attached Files:

Notes
(0003727) polluks    2022-04-04 13:04	Indeed $ grep usr/bin/env magic/Magdir/commands 0 search/1 #!/usr/bin/env\ zsh Paul Falstad's zsh script text executable 0 string/fwt #!\ /usr/bin/env\ bash Bourne-Again shell script text executable 0 string/fwt #!\ /usr/bin/env\ fish fish shell script text executable 0 string/fwt #!\ /usr/bin/env\ execlineb execline script text executable
(0003728) christos    2022-04-04 16:13	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
333	[file] General	feature	N/A	2022-03-24 08:26	2022-03-24 08:26
Reporter:	evyatar	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Introduce a magic_file_at() function
Description:	I suggest introducing a new libmagic API function: magic_file_at which will have the signature: const char *magic_file_at(magic_t cookie, int dirfd, const char *path) It behaves exactly like magic_file() except that if path is relative then it is interpreted as a relative path to the directory referred to by dirfd except if dirfd is negative in which case path is interpreted as a relative path to the current working directory. This is analogous to the openat() family of syscalls (except that AT_FDCWD is changed with any negative value). The rationale behind this addition is laid out in the Linux mapage for open(2) but also, in my personal experience, it simplifies the use of readdir() greatly as no string copying needs to take place to call magic_file().
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
283	[file] General	feature	N/A	2021-08-17 06:03	2022-03-21 23:34
Reporter:	polluks	Platform:	PowerBook5,8
Assigned To:	christos	OS:	MorphOS
Priority:	normal	OS Version:	3.15
Status:	resolved	Product Version:	5.40
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.41
		Target Version:
Summary:	More X11
Description:	Please use official name Added bitmap
Tags:
Steps To Reproduce:	--- xwindows.bak 2020-06-19 14:19:13 +0200 +++ xwindow 2021-08-17 00:57:25 +0200 @@ -1,7 +1,7 @@    #------------------------------------------------------------------------------  # $File: xwindows,v 1.11 2019/04/19 00:42:27 christos Exp $ -# xwindows: file(1) magic for various X/Window system file formats. +# xwindow: file(1) magic for various X Window System file formats.    # Compiled X Keymap  # XKM (compiled X keymap) files (including version and byte ordering) @@ -33,3 +33,7 @@  !:mime image/x-xcursor  >10 leshort x version %d  >>8 leshort x \b.%d + +# X bitmap https://en.wikipedia.org/wiki/X_BitMap +0 string #define\ +>8 regex [a-zA-Z0-9]+_width xbm image
Additional Information:
System Description
Attached Files:

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
330	[file] General	minor	have not tried	2022-03-19 15:41	2022-03-21 23:28
Reporter:	polluks	Platform:	MacBook Pro
Assigned To:	christos	OS:	macOS
Priority:	normal	OS Version:	12.1
Status:	assigned	Product Version:	5.41
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	msdos: ZIP self-extracting archive
Description:	file did not recognize the ZIP, unzip worked fine
Tags:	magic, zip
Steps To Reproduce:	IFAZE475.EXE: MS-DOS executable, NE for MS Windows 3.x (EXE) │00003E60 4D 00 DD 0A 00 00 4C 9F 00 00 9E 03 CF 06 50 4B │◆│......L.......PK│ │00003E70 03 04 14 00 00 80 08 00 F3 80 73 20 59 59 74 17 │▒│..........s YYt.│
Additional Information:	http://cd.textfiles.com/psl/pslv5nv05/WIN/GRAPHICS/IFAZE475.ZIP
System Description	Apple M1
Attached Files:

Notes
(0003719) christos    2022-03-21 21:42	It is a self-extracting zip (even unzip says so)... What would you have file say?
(0003720) polluks    2022-03-21 23:28	File should say: This is not a plain NE exe but a ZIP.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
326	[file] General	feature	always	2022-03-04 00:59	2022-03-21 21:37
Reporter:	aichingm	Platform:	amd64
Assigned To:	christos	OS:	Linux
Priority:	normal	OS Version:	5.16
Status:	resolved	Product Version:	5.41
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.42
		Target Version:
Summary:	add support for QGis files which are currently identified as HTML document
Description:	QGIS: A Free and Open Source Geographic Information System File format descriptions: https://github.com/qgis/QGIS/blob/master/rpm/sources/qgis-mime.xml
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	qgis-project.qgs (3,709 bytes) 2022-03-04 00:59 https://bugs.astron.com/file_download.php?file_id=266&type=bug

Notes
(0003718) christos    2022-03-21 21:37	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
325	[file] General	trivial	always	2022-02-28 14:20	2022-03-21 21:28
Reporter:	wolfgangwalther	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.41
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.42
		Target Version:
Summary:	WOFF / WOFF2 fonts have no mimetype associated
Description:	WOFF / WOFF2 files are correctly identified as such, but the returned mimetype is application/octet-stream, even though RFC8081 [1] defines font/woff and font/woff2 as mimetypes for those files types. [1]: https://www.rfc-editor.org/rfc/rfc8081#section-4.4.5
Tags:	magic
Steps To Reproduce:	Using any example woff/woff2 file (e.g. https://filesamples.com/formats/woff): % file fontawesome-webfont.woff fontawesome-webfont.woff: Web Open Font Format, TrueType, length 98164, version 4.7 % file --mime-type fontawesome-webfont.woff fontawesome-webfont.woff: application/octet-stream
Additional Information:
Attached Files:

Notes
(0003717) christos    2022-03-21 21:28	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
328	[file] General	minor	always	2022-03-15 10:49	2022-03-21 21:26
Reporter:	adepasquale	Platform:
Assigned To:	christos	OS:
Priority:	low	OS Version:
Status:	resolved	Product Version:	5.41
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.42
		Target Version:
Summary:	Add various missing MIME-Types
Description:	Add missing MIME-Types for: - ACE archives - Windows CHM - Windows URL - Windows LNK
Tags:	magic
Steps To Reproduce:
Additional Information:
Attached Files:	mimetypes.FILE5_41.patch (1,674 bytes) 2022-03-15 10:49 https://bugs.astron.com/file_download.php?file_id=268&type=bug

Notes
(0003716) christos    2022-03-21 21:26	Committed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
327	[file] General	minor	always	2022-03-15 00:28	2022-03-21 21:24
Reporter:	vinc17	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.41
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.42
		Target Version:
Summary:	fails to detect a json file as JSON data
Description:	file 5.41 fails to detect the attached json file as JSON data.
Tags:
Steps To Reproduce:	$ file Q3235109.json Q3235109.json: ASCII text, with very long lines (2409), with no line terminators And with the -d option, I can see: "[try json 0]".
Additional Information:	The json_pp utility doesn't detect any issue on this file.
Attached Files:	Q3235109.json (2,409 bytes) 2022-03-15 00:28 https://bugs.astron.com/file_download.php?file_id=267&type=bug

Notes
(0003711) polluks    2022-03-21 14:04	By the way "cc -DTEST is_json.c" and "cc -DTEST is_tar.c" are broken, "cc -DTEST is_csv.c" still works.
(0003712) polluks    2022-03-21 14:19	--- is_json.c.bak 2022-03-21 15:13:15.933289900 +0100 +++ is_json.c 2022-03-21 15:14:48.814366000 +0100 @@ -37,6 +37,8 @@  #include <string.h>  #include "magic.h" +#else +#include <stddef.h>  #endif  #ifdef DEBUG
(0003715) christos    2022-03-21 21:24	Bumped recursion limit.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
331	[file] General	minor	have not tried	2022-03-20 23:48	2022-03-21 19:58
Reporter:	polluks	Platform:	MacBook Pro
Assigned To:	christos	OS:	macOS
Priority:	normal	OS Version:	12.3
Status:	resolved	Product Version:	5.41
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.42
		Target Version:
Summary:	macOS: check fails
Description:	Running test: ../tests/CVE-2014-1943.testfile ../tests/CVE-2014-1943.testfile: Apple Driver Map, blocksize 0 Running test: ../tests/JW07022A.mp3.testfile ../tests/JW07022A.mp3.testfile: Audio file with ID3 version 2.2.0, contains: MPEG ADTS, layer III, v1, 96 kbps, 44.1 kHz, Monaural Running test: ../tests/android-vdex-1.testfile ../tests/android-vdex-1.testfile: Android vdex file, verifier deps version: 021, dex section version: 002, number of dex files: 4, verifier deps size: 106328 Running test: ../tests/android-vdex-2.testfile ../tests/android-vdex-2.testfile: Android vdex file, being processed by dex2oat, verifier deps version: 019, dex section version: 002, number of dex files: 1, verifier deps size: 1016 Running test: ../tests/arj.testfile ../tests/arj.testfile: ARJ archive data, v11, slash-switched, created 5 1980+48, original name: example_m0.arj, os: Unix test: ERROR: result was (len 97) ARJ archive data, v11, slash-switched, created 5 1980+48, original name: example_m0.arj, os: Unix expected (len 79) ARJ archive data, v11, slash-switched, original name: example_m0.arj, OS: Unix make[2]: *** [check-local] Error 1 make[1]: *** [check-am] Error 2 make: *** [check-recursive] Error 1
Tags:	build
Steps To Reproduce:
Additional Information:
System Description	Apple M1
Attached Files:

Notes
(0003714) christos    2022-03-21 19:58	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
329	[file] General	feature	N/A	2022-03-17 14:35	2022-03-21 19:57
Reporter:	polluks	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.42
		Target Version:
Summary:	Another IFF format
Description:	--- iff.bak 2021-12-06 12:05:46.956819300 +0100 +++ iff 2022-03-17 15:32:22.461280200 +0100 @@ -45,6 +45,7 @@  >8 string ACBM \b, ACBM continuous image  >8 string FAXX \b, FAXX fax image  >8 string STFX \b, ST-Fax image +>8 string IMAGIHDR \b, CD-i image  # other formats  >8 string FTXT \b, FTXT formatted text  >8 string CTLG \b, CTLG message catalog
Tags:	magic
Steps To Reproduce:
Additional Information:	See also https://github.com/jsummers/deark/issues/40
Attached Files:

Notes
(0003713) christos    2022-03-21 19:57	Thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
323	[file] General	minor	always	2022-02-27 13:30	2022-03-21 19:55
Reporter:	vmurashev	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:	5.41
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	2 test samples are broken
Description:	If to fix issue 0000322 it becomes clear that 2 test samples are broken   - fit-map-data   - regex-eol --- /mnt/c/yr/file/tests/regex-eol.testfile: Ansible Vault, version 1.1, encryption AES256 file_test: ERROR: result was (len 45) Ansible Vault, version 1.1, encryption AES256 expected (len 57) Ansible Vault text, version 1.1, using AES256 encryption --- /mnt/c/yr/file/tests/fit-map-data.testfile: FIT Map data, unit id 65536, serial 3879446968, Sat May 31 13:00:34 2014, manufacturer 1 (garmin), product 1632, type 4 (Activity) file_test: ERROR: result was (len 130) FIT Map data, unit id 65536, serial 3879446968, Sat May 31 13:00:34 2014, manufacturer 1 (garmin), product 1632, type 4 (Activity) expected (len 131) FIT Map data, unit id 65536, serial 3879446968, Sat May 31 10:00:34 2014, manufacturer 1 (garmin), product 1632, type 4 (Activity)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
322	[file] General	major	always	2022-02-27 13:22	2022-03-16 12:03
Reporter:	vmurashev	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.41
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.42
		Target Version:
Summary:	test should not skip underlying OS errors (e.g. file not found)
Description:	Please take a look at tests/test.c magic cookie is opened with flag MAGIC_NONE as result test exits with zero exit code even if input file for testing is not found I believe that for testing magic cookie should be opened with flag MAGIC_ERROR
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003709) christos    2022-03-16 12:03	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
321	[file] General	minor	have not tried	2022-02-27 13:12	2022-03-16 11:59
Reporter:	vmurashev	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.41
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.42
		Target Version:
Summary:	memory double free if to invoke test with unexpected count of arguments
Description:	Please take a looks at test/test.c     if (argc != 3) {         (void)fprintf(stderr, "Usage: %s TEST-FILE RESULT\n", prog);         magic_close(ms);         goto bad;     } ... bad:     free(desired);     magic_close(ms);     return e; You can see that magic_close(ms) is called twice in such case
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003708) christos    2022-03-16 11:59	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
320	[file] General	tweak	always	2022-02-21 16:38	2022-02-21 19:21
Reporter:	BEEDELLROKEJULIANLOCKHART	Platform:
Assigned To:	christos	OS:
Priority:	low	OS Version:
Status:	feedback	Product Version:	5.41
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	'file' reports encodement as merely 'ISO-8859' rather than specifically 'ISO-8859-1' or 'ISO-8859-15' or 'ISO-8859-14'.
Description:	'file' reports encodement as merely 'ISO-8859' rather than specifically 'ISO-8859-1' or 'ISO-8859-15' or 'ISO-8859-14', which means that the informqation is not useful for me, because I must know more specifically the current encodement to be able to configure utilities that are similar to 'http://invent.kde.org/utilities/kate' to
Tags:
Steps To Reproduce:	Install Windows 10. Create one '.deskthemepack'-file by exporting the current theme. Install 'http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Server/x86_64/iso'. Install 'http://src.fedoraproject.org/rpms/file'. Utilise 'http://invent.kde.org/utilities/ark' to extract the '.theme'-file from the '.deskthemepack'-archive-file. Invoke '/usr/bin/file' with the path of the '.theme'-file of text as the sole argument as '/usr/bin/file 'file.theme''. Alternatively, or conclusively, utilise 'file' to provide the encodement of any file that contains text whose encodement is 'ISO-8859'.
Additional Information:
Attached Files:

Notes
(0003706) christos    2022-02-21 19:21	The question is how to tell the difference? For example while you can probably tell the difference between 8859-1 and 8859-14 by using a Celtic dictionary, it would be nearly impossible to tell the difference between 8859-1 and 8859-15.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
309	[file] General	minor	always	2022-01-20 14:52	2022-02-21 07:52
Reporter:	malat	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Add support for JPEG-XL
Description:	It would be nice to add support for JPEG-XL : ``` % convert -size 512x512 -depth 8 xc:black black.pgm % cjxl black.pgm black.jxl % file black.jxl black.jxl: data ```
Tags:
Steps To Reproduce:
Additional Information:	Here is the typical bits to check: * https://github.com/libjxl/libjxl/blob/main/plugins/mime/image-jxl.xml ``` <?xml version="1.0" encoding="UTF-8"?> <mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info">   <mime-type type="image/jxl">     <comment>JPEG XL image</comment>     <comment xml:lang="fr">image JPEG XL</comment>     <comment xml:lang="nl">JPEG XL afbeelding</comment>     <magic priority="50">       <match type="string" offset="0" value="\xFF\x0A"/>       <match type="string" offset="0" value="\0\0\0\x0CJXL \x0D\x0A\x87\x0A"/>     </magic>     <glob pattern="*.jxl"/>   </mime-type> </mime-info> ```
Attached Files:

Notes
(0003703) christos    2022-02-20 18:28	What version of file are you using? The magic seems to be there in HEAD: # fgrep -i JPEG * | fgrep -i xl jpeg:# JPEG XL jpeg:0 string \xff\x0a JPEG XL codestream jpeg:# JPEG XL (transcoded JPEG file) jpeg:0 string \x00\x00\x00\x0cJXL\x20\x0d\x0a\x87\x0a JPEG XL container
(0003704) malat    2022-02-21 07:51	Indeed, I was using file from Debian/bullseye. Closing.
(0003705) malat    2022-02-21 07:52	For reference: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004081

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
319	[file] General	major	always	2022-02-17 11:19	2022-02-19 22:49
Reporter:	jmp3r	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.41
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.42
		Target Version:
Summary:	Text files are identified as data
Description:	Some text files could not be identified correctly, tested with 5.39, 5.41 wise_lang - 3 language ini files log_data - samples log files
Tags:
Steps To Reproduce:	Scan any file from attached archives and check that the output of file utility will "data" but these files are simple text files.
Additional Information:
Attached Files:	wise_lang.zip (6,079 bytes) 2022-02-17 11:19 https://bugs.astron.com/file_download.php?file_id=264&type=bug log_data.zip (97,149 bytes) 2022-02-17 11:19 https://bugs.astron.com/file_download.php?file_id=265&type=bug

Notes
(0003702) christos    2022-02-19 22:49	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
316	[file] General	minor	always	2022-01-31 14:59	2022-02-19 22:36
Reporter:	karagian	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.41
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.42
		Target Version:
Summary:	.dbf files misidentified as "amd 29k coff prebar executable"
Description:	file identifies .dbf files as "amd 29k coff prebar executable".
Tags:
Steps To Reproduce:	you can test file on attached file
Additional Information:	amd 29k coff prebar executable checks for the first two bytes, according to Magdir/varied.out and expected octal 01572 0 beshort 01572 amd 29k coff prebar executable According to dbf specification (found in this link https://www.dbase.com/Knowledgebase/INT/db7_file_fmt.htm ) a DBASE level 5 file, last updated in 2022 (makes second byte 122, that's 122 years after 1900 :P ), matches the above 2-byte signature, so it gets misidentified as executable
Attached Files:	DiorthPolykastrou062.dbf (2,574 bytes) 2022-01-31 14:59 https://bugs.astron.com/file_download.php?file_id=261&type=bug

Notes
(0003692) polluks    2022-02-02 12:13	Raise priority of Magdir/database and check two more bytes... "12-13 2 bytes Reserved; filled with zeros."
(0003701) christos    2022-02-19 22:36	Bumped version of dbf.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
317	[file] General	major	always	2022-02-02 11:18	2022-02-15 13:57
Reporter:	ssaschaa	Platform:	MacBook Pro M1 arm64
Assigned To:	christos	OS:	MacOS
Priority:	normal	OS Version:	12.2 Darwin 21.3
Status:	assigned	Product Version:	5.41
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	OOXML mime-type fails with "application/x-decompression-error-gzip-Unknown-compression-format"
Description:	When trying to get the mime-type of e.g. Excel OOXML file at MacOS decompression fails and MimeType "application/x-decompression-error-gzip-Unknown-compression-format" is returned instead of "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet". Tried both: compilation and test as ARM64 and X86_64 binary
Tags:	bug, compression
Steps To Reproduce:	git clone https://github.com/file/file cd ./file autoreconf -i ./configure make check ./src/file -m ./magic/magic.mgc --mime-type /tmp/Excel_Test.xlsx
Additional Information:	Tried both: compilation and test as ARM64 and X86_64 binary
Attached Files:	Excel_Test.xlsx (8,460 bytes) 2022-02-02 11:18 https://bugs.astron.com/file_download.php?file_id=262&type=bug

Notes
(0003699) christos    2022-02-15 13:32	Tried to reproduce it, but could not: [8:32am] 1761>./file -m ../magic/magic.mgc --mime-type Excel_Test.xlsx Excel_Test.xlsx: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet [8:32am] 1762>uname -a Darwin vpn1-1.astron.com 21.2.0 Darwin Kernel Version 21.2.0: Sun Nov 28 20:29:10 PST 2021; root:xnu-8019.61.5~1/RELEASE_ARM64_T8101 arm64
(0003700) ssaschaa    2022-02-15 13:57	Sorry, I forgot to add the CLI switch "-z" for decompression attempts. On Linux I get (as expected): /tmp/Excel_Test.xlsx: text/xml; charset=us-ascii compressed-encoding=application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; charset=binary But on MacOS I get: /tmp/Excel_Test.xlsx: application/x-decompression-error-gzip-Unknown-compression-format

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
318	[file] General	feature	N/A	2022-02-04 23:55	2022-02-15 13:01
Reporter:	polluks	Platform:	PowerBook5,8
Assigned To:	christos	OS:	MorphOS
Priority:	normal	OS Version:	3.15
Status:	resolved	Product Version:	5.41
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.42
		Target Version:
Summary:	Added Oric
Description:	See http://fileformats.archiveteam.org/wiki/TAP_(Oric)
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:	oric (374 bytes) 2022-02-04 23:55 https://bugs.astron.com/file_download.php?file_id=263&type=bug

Notes
(0003698) christos    2022-02-15 13:01	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
314	[file] General	minor	always	2022-01-29 19:10	2022-02-15 12:58
Reporter:	gms	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.42
		Target Version:
Summary:	Add magic for Pronto CCF files
Description:	I've attached a small magic section for identifying Philips Pronto IR remote control CCF exchange format files. Example: file -m ccf_magic Panasonic.ccf Panasonic.ccf: Philips Pronto IR remote control CCF Remote control databases such as remote central carry a lot of CCF files, cf. e.g. http://files.remotecentral.com/download/45/pan-air-csakr.zip.html for the above example file. I've also tested it with other CCF files. I couldn't find real documentation for the CCF file format, but there are some open source utilities which use these magic bytes. See for example my extract utility: https://github.com/gsauthof/pronto-ccf/blob/78084a46109356d2bbf6e8d86eeb2f051d4e6022/ccf2pulse.py#L150
Tags:	magic
Steps To Reproduce:
Additional Information:
Attached Files:	ccf_magic (294 bytes) 2022-01-29 19:10 https://bugs.astron.com/file_download.php?file_id=259&type=bug

Notes
(0003697) christos    2022-02-15 12:58	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
315	[file] General	minor	always	2022-01-31 00:25	2022-02-14 23:57
Reporter:	polluks	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.41
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.42
		Target Version:
Summary:	Fixed console
Description:	Fixed my newer Atari Lynx cartridge dump
Tags:	bug
Steps To Reproduce:	$ file -m console *.lnx Solitaire_[AtariGamer.Com](Homebrew).lnx: Lynx cartridge, bank 0 256k, bank 1 256k, "Solitare pack for Lynx ", "Karris project " a.lnx: Lynx cartridge, bank 0 256k, "Cart name ", "Manufacturer " cart.lnx: Lynx cartridge, bank 0 512k, bank 1 512k, "Cart name ", "Manufacturer "
Additional Information:
Attached Files:	console (38,975 bytes) 2022-01-31 00:25 https://bugs.astron.com/file_download.php?file_id=260&type=bug

Notes
(0003696) christos    2022-02-14 23:57	Added thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
311	[file] General	feature	N/A	2022-01-21 16:28	2022-02-14 16:51
Reporter:	ylep	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.42
		Target Version:
Summary:	New magic for the NIfTI neuroimaging file format
Description:	I would like to propose the attached magic rules for inclusion, which are for identifying files in NIfTI format. NIfTI is a widely used format for image storage and exchange in the neuroimaging community, see https://nifti.nimh.nih.gov/. I went beyond mere identification of the file type, and implemented rules for printing some high-level metadata (image size, resolution, datatype, etc.) which I find really useful, but I would understand if you think it is too much to include in the main database. Test files can be found at the links below: https://nifti.nimh.nih.gov/nifti-1/data/ https://nifti.nimh.nih.gov/pub/dist/data/nifti2
Tags:	magic
Steps To Reproduce:
Additional Information:
Attached Files:	nifti.magic (4,992 bytes) 2022-01-21 16:28 https://bugs.astron.com/file_download.php?file_id=258&type=bug

Notes
(0003695) christos    2022-02-14 16:51	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
308	[file] General	minor	always	2022-01-18 10:39	2022-02-14 16:47
Reporter:	adepasquale	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.41
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.42
		Target Version:
Summary:	Fix and improve ARJ file information
Description:	Current file 5.41 has an issue parsing the "original filename" from ARJ archive headers (wrong offset). I updated the offset, as well as added more information based on open source documentation: https://fossies.org/linux/unarj/unarj.c https://www.fileformat.info/format/arj/corion.htm http://hmelnov.icc.ru/geos/scripts/WWWBinV.dll/ShowR?ARJ.rfh See the attached patch and hexdump of a sample file header (use xxd -r to restore). Output before/after applying the patch: test.arj: ARJ archive data, v11, slash-switched, original name: , os: Unix test.arj: ARJ archive data, v11, slash-switched, original name: example_m0.arj, OS: Unix
Tags:	magic
Steps To Reproduce:
Additional Information:
Attached Files:	arj.patch (1,335 bytes) 2022-01-18 10:39 https://bugs.astron.com/file_download.php?file_id=255&type=bug test_arj.hex (262 bytes) 2022-01-18 10:39 https://bugs.astron.com/file_download.php?file_id=256&type=bug

Notes
(0003694) christos    2022-02-14 16:47	Committed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
310	[file] General	major	always	2022-01-21 14:50	2022-02-14 16:39
Reporter:	p870613	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.41
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.42
		Target Version:
Summary:	AddressSanitizer: stack-buffer-overflow on address 0x7ffc1ece1ae0 at pc 0x00000050bb19 bp 0x7ffc1ecdf090 sp 0x7ffc1ecdf088
Description:	- version     ```     ➜ src ./file --version     file-5.41     magic file from /usr/local/share/misc/magic     ```     - at branch 4c94d085 - environment     ```     ➜ release git:(master) uname -a     Linux lin-System-Product-Name 5.11.0-40-generic 00000440000018:0000020.04.2-Ubuntu SMP Tue Oct 26 18:07:44 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux     ➜ release git:(master) lsb_release -r     Release: 20.04     ``` - reproduce     ```     git clone https://github.com/file/file.git     cd file     autoreconf -i     ./configure CC=gcc CXX=g++ CFLAGS="-g -fsanitize=address" --disable-shared     make V=1 all     ./src/file -m ./magic/magic.mgc ./poc     ``` - asan ``` ================================================================= ==1321923==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffd284ba010 at pc 0x56188a508267 bp 0x7ffd284b75f0 sp 0x7ffd284b75e0 READ of size 1 at 0x7ffd284ba010 thread T0     #0 0x56188a508266 in strlcpy /home/lin/file/src/strlcpy.c:49     0000001 0x56188a4fec64 in file_copystr /home/lin/file/src/funcs.c:59     0000002 0x56188a521563 in do_core_note /home/lin/file/src/readelf.c:918     0000003 0x56188a523610 in donote /home/lin/file/src/readelf.c:1236     0000004 0x56188a51e0be in dophn_core /home/lin/file/src/readelf.c:412     0000005 0x56188a52753c in file_tryelf /home/lin/file/src/elfclass.h:43     0000006 0x56188a50113e in file_buffer /home/lin/file/src/funcs.c:433     0000007 0x56188a4e0a33 in file_or_fd /home/lin/file/src/magic.c:533     0000008 0x56188a4e0376 in magic_file /home/lin/file/src/magic.c:417     #9 0x56188a4dd9d4 in process /home/lin/file/src/file.c:555     0000010 0x56188a4dce13 in main /home/lin/file/src/file.c:428     0000011 0x7f4a175d40b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)     0000012 0x56188a4dc28d in _start (/home/lin/file/src/file+0x1728d) Address 0x7ffd284ba010 is located in stack of thread T0 at offset 8384 in frame     #0 0x56188a51d977 in dophn_core /home/lin/file/src/readelf.c:351   This frame has 3 object(s):     [32, 64) 'ph32' (line 352)     [96, 152) 'ph64' (line 353)     [192, 8384) 'nbuf' (line 355) <== Memory access at offset 8384 overflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork       (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow /home/lin/file/src/strlcpy.c:49 in strlcpy Shadow bytes around the buggy address:   0x10002508f3b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   0x10002508f3c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   0x10002508f3d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   0x10002508f3e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   0x10002508f3f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x10002508f400: 00 00[f3]f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3   0x10002508f410: f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3   0x10002508f420: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00   0x10002508f430: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1   0x10002508f440: 02 f2 04 f2 04 f2 00 00 00 00 00 00 04 f2 f2 f2   0x10002508f450: f2 f2 00 00 00 00 00 00 00 00 f2 f2 f2 f2 00 00 Shadow byte legend (one shadow byte represents 8 application bytes):   Addressable: 00   Partially addressable: 01 02 03 04 05 06 07   Heap left redzone: fa   Freed heap region: fd   Stack left redzone: f1   Stack mid redzone: f2   Stack right redzone: f3   Stack after return: f5   Stack use after scope: f8   Global redzone: f9   Global init order: f6   Poisoned by user: f7   Container overflow: fc   Array cookie: ac   Intra object redzone: bb   ASan internal: fe   Left alloca redzone: ca   Right alloca redzone: cb   Shadow gap: cc ==1321923==ABORTING ```
Tags:
Steps To Reproduce:	git clone https://github.com/file/file.git  cd file  autoreconf -i ./configure CC=gcc CXX=g++ CFLAGS="-g -fsanitize=address" --disable-shared  make V=1 all  ./src/file -m ./magic/magic.mgc ./poc
Additional Information:
Attached Files:	poc (28,105 bytes) 2022-01-21 14:50 https://bugs.astron.com/file_download.php?file_id=257&type=bug

Notes
(0003693) christos    2022-02-14 16:39	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
313	[tcsh] General	minor	always	2022-01-22 15:10	2022-01-22 15:10
Reporter:	dgusev	Platform:	AMD64
Assigned To:		OS:	FreeBSD
Priority:	normal	OS Version:	13.0
Status:	new	Product Version:	6.21.00
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	On exit history file is overwitten without merging
Description:	Settings: set history = 65535 set savehist = ( 65535 merge ) According to the tcsh manual page (description section of the "history -S|-L|-M [filename]"): "If the second word of savehist is set to `merge', the history list is merged with the existing history file instead of replacing it" But actually it overwrites the history file without merging. I get the same results using "history -S" or on exit from tcsh session. Also tried to set lower history number to 1000 etc. Same results.
Tags:
Steps To Reproduce:	1. Set history options in "~/.cshrc" or "/etc/csh.cshrc": set history = 65535 set savehist = ( 65535 merge ) 2. Open 2 tcsh sessions. 3. Enter some commands in the first session and then save the history by using "history -S" command or by exiting from the session. 4. Save history the same way in the second session. History file will be overwritten, the new commands from 1st session will be lost.
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
305	[file] General	major	always	2021-12-23 15:18	2022-01-10 19:32
Reporter:	felixsch	Platform:	linux
Assigned To:	christos	OS:	ubuntu
Priority:	normal	OS Version:	impish
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.42
		Target Version:
Summary:	file utility fails on a simple binary file with ERROR: (null)
Description:	The file utility fails on the attached simple binary file with output     tmp.bin: ERROR: (null) It turns out that the first 4 bytes trigger this issue, in fact the error occurs if the binary file starts with 0x02020100 or 0x02020200 file-5.38 gives the expected result     tmp.bin: data
Tags:
Steps To Reproduce:	Run the command     `file tmp.bin` on the attached file
Additional Information:	I encountered the problem on ubuntu impish with file utility version 5.39. The attached file is just the head of a large binary file. After cloning the repository and doing a `git bisect` it turned out that the problematic commit is commit 2ca292bcdf217bfddeeeaad1adc38c716ffab181 (HEAD, refs/bisect/bad) Author: Christos Zoulas <christos@zoulas.com> Date: Sun Mar 15 16:44:37 2020 +0000     Improve on Windoes Precompiled INFO files (Joerg Jenderek) PS: I used the github repo to reproduce and bisect, but with the commit message above it should be possible to find the corresponding commit in the original repo. The issue is still present in the actual master (commit message)     PR/304: zachs18: Allow whitespace in netpbm sizes.
Attached Files:	tmp.bin (32 bytes) 2021-12-23 15:18 https://bugs.astron.com/file_download.php?file_id=252&type=bug tmp2.bin (32 bytes) 2022-01-10 19:00 https://bugs.astron.com/file_download.php?file_id=254&type=bug

Notes
(0003686) christos    2022-01-10 15:04	Thanks, but the problem seems to be fixed; I can't reproduce this file 5.41...
(0003688) felixsch    2022-01-10 19:00	Oh sorry, I must be in idiot. When playing around with starting signature of the file I tried different signatures to narrow the bug, and then I attached the wrong file. In fact tmp.bin starts with 0x02020300, and this is working. Please try the newly attached file tmp2.bin, which should start with 0x02020200, if you are patient enough. I get the issue with file-5.41 in the latest ubuntu:jammy docker container.
(0003689) christos    2022-01-10 19:32	Spurious mprint() return value.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
307	[file] General	minor	always	2022-01-02 20:01	2022-01-10 14:15
Reporter:	Fabrice	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.41
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.42
		Target Version:
Summary:	Build failure with gcc 4.8
Description:	We have the following build failure on buildroot with file 5.41 and gcc 4.8 readelf.c: In function 'do_auxv_note': readelf.c:1046:2: error: 'for' loop initial declarations are only allowed in C99 mode   for (size_t off = 0; off + elsize <= descsz; off += elsize) {   ^ funcs.c:93:2: error: 'for' loop initial declarations are only allowed in C99 mode   for (const char *p = fmt; *p; p++) {   ^ Please find a patch below Full build log:  - http://autobuild.buildroot.org/results/31c/31cbc313fceb84c0cbb1969fca5ac44244871dbc/build-end.log
Tags:	build
Steps To Reproduce:
Additional Information:
Attached Files:	0001-fix-build-with-gcc-4.8.patch (3,086 bytes) 2022-01-02 20:01 https://bugs.astron.com/file_download.php?file_id=253&type=bug

Notes
(0003685) christos    2022-01-10 14:15	fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
302	[file] General	minor	have not tried	2021-12-04 03:35	2021-12-06 22:13
Reporter:	calestyo	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:	5.41
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	GPT not correctly detected as such, because of it's protective MBR
Description:	Hey. A file that contains a GPT (GUID Partition Table) is nonetheless detected as MBR, which is probably because every GPT contains a protective MBR just at the position where the regular MBR would be. E.g.: # gdisk -l example.img GPT fdisk (gdisk) version 1.0.6 Partition table scan:   MBR: protective   BSD: not present   APM: not present   GPT: present Found valid GPT with protective MBR; using GPT. Disk example.img: 16777216 sectors, 8.0 GiB Sector size (logical): 512 bytes Disk identifier (GUID): C93252EC-C2A3-41C8-9A12-ECF030C66D7E Partition table holds up to 128 entries Main partition table begins at sector 2 and ends at sector 33 First usable sector is 34, last usable sector is 16777182 Partitions will be aligned on 2048-sector boundaries Total free space is 2014 sectors (1007.0 KiB) Number Start (sector) End (sector) Size Code Name    1 2048 67583 32.0 MiB EF00 EFI system partition    2 67584 16777182 8.0 GiB 8300 Linux filesystem whereas file only detects the MBR: # file example.img example.img: DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 16777215 sectors, extended partition table (last) Not really sure how one should (safely) detect a GPT. The protective MBR always looks like this: Expert command (? for help): o Disk size is 16777216 sectors (8.0 GiB) MBR disk identifier: 0x00000000 MBR partitions: Number Boot Start Sector End Sector Status Code    1 1 16777215 primary 0xEE i.e. always type 0xEE ... but that alone is AFAIU not enough to say there's a GPT... furthermore, GPTs may not use a protective MBR at all. The best is perhaps to just rely on the GPT signature, which is: EFI PART at 0x0 (and I think with respect to the endianess) (see https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_table_header_(LBA_1) ) Not sure if it makes sense to check for the backup GPT, probably not. Cheers, Chris.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003682) christos    2021-12-06 20:07	file just does not look after the MBR for the GPT information... It could be made to look, but currently it does not.
(0003683) calestyo    2021-12-06 22:13	Guess that would make sense... just like it looks deeper into various container formats to find out what's actually inside.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
301	[file] General	minor	N/A	2021-11-24 23:48	2021-12-06 19:59
Reporter:	rowlap	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	feedback	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	sysstat magic
Description:	Please find attached magic rules to recognise data files generated by sysstat. Discussion thread https://github.com/sysstat/sysstat/discussions/297
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	sysstat.magic (288 bytes) 2021-11-24 23:48 https://bugs.astron.com/file_download.php?file_id=248&type=bug

Notes
(0003681) christos    2021-12-06 19:59	Have you read "new magic guidelines" in https://github.com/file/file? It is strongly recommended to not submit magic with an initial prefix of <= 16 bits.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
303	[file] General	minor	have not tried	2021-12-05 15:15	2021-12-06 19:33
Reporter:	polluks	Platform:	PowerBook5,8
Assigned To:	christos	OS:	MorphOS
Priority:	normal	OS Version:	3.15
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.42
		Target Version:
Summary:	False positive PCP
Description:	Because it's a 3DS...
Tags:
Steps To Reproduce:	> file * ball.3ds: 3D Studio model myAdder.3DS: 3D Studio model myAnaconda.3ds: 3D Studio model myCoriolis.3DS: 3D Studio model myMissile.3DS: PCP memory mapped values (V.512) myThargoid.3ds: 3D Studio model
Additional Information:
System Description
Attached Files:	myMissile.3DS (1,366 bytes) 2021-12-05 15:15 https://bugs.astron.com/file_download.php?file_id=249&type=bug

Notes
(0003679) polluks    2021-12-06 12:22	5.41 says "PCP memory mapped values (V.131072)" because of sgi vs cad
(0003680) christos    2021-12-06 19:33	bumped strength

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
300	[file] General	minor	always	2021-11-20 08:45	2021-11-21 19:40
Reporter:	JoshuaFern	Platform:	Linux
Assigned To:	christos	OS:	NixOS
Priority:	normal	OS Version:	21.11
Status:	resolved	Product Version:	5.41
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.42
		Target Version:
Summary:	Long GIF image doesn't show correct resolution
Description:	I have a very long GIF, 630 x 52337. When running file the larger resolution is blank.
Tags:
Steps To Reproduce:	Run the following: file acidshowcase.gif acidshowcase.gif: GIF image data, version 89a, 630 x
Additional Information:	I'm new to file, hopefully this bug report is valid and useful. I will upload the file in question upon request, it's too large to upload to this bugtracker.
Attached Files:

Notes
(0003678) christos    2021-11-20 13:34	No need, I can reproduce with: $ pbmmake 630 52337 | pamtogif > /tmp/foo.gif Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
293	[file] General	minor	always	2021-10-20 13:01	2021-11-19 16:49
Reporter:	Yardanico	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	feedback	Product Version:	5.40
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	file is too strict with Nim file detection
Description:	https://bugs.astron.com/view.php?id=273 reported that Nim wasn't in the file database and Nim magic was subsequently added to the `file`, but it's too strict - the current magic definition was clearly written for `koch.nim` specifically, but Nim is a programming language with a lot of possible code. I think checking for `import` and `let` is enough for some minimal level of detection (if no other language matches that), and then for more accurate checking you can also check for the existence of `proc` or `echo`. I'm aware that quite a lot of languages have both`import` and `let` as keywords, but I think that file's magics would be enough to differentiate between them?
Tags:	bug, magic, nim-lang
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003660) christos    2021-10-28 15:49	Well, you know the language better, why don't you propose a patch?

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
291	[file] General	minor	have not tried	2021-09-24 14:09	2021-11-16 19:35
Reporter:	rootkea	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	scan-build reports multiple logic errors
Description:	Hello! On latest master, scan-build[0] reports multiple logical errors. Please see the scan-build report here: https://rootkea.gitlab.io/file/scan-build/ Here's the .gitlab-ci.yml which generated this scan-build report: https://gitlab.com/rootkea/file/-/raw/gitlab-scan-build/.gitlab-ci.yml Thanks! [0] https://clang-analyzer.llvm.org/scan-build
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003664) christos    2021-10-28 16:37	Fixed all but the vfork() ones. Yes, lseek(2)/close(2) are not strictly legal to call after vfork(2), but if you follow the strict rules, then the number of cases you can use vfork(2) become close to 0.
(0003667) rootkea    2021-10-29 05:11	Can we replace `vfork()` with safer `posix_spawn()` as suggested by scan-build?
(0003677) christos    2021-11-16 19:35	We can, and perhaps we should. It is a bit of work though... We'd also want to keep the old vfork code (or change it to use fork) for systems that don't have posix_spawn

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
271	[file] General	minor	always	2021-06-13 06:11	2021-11-14 12:21
Reporter:	DaarkWel	Platform:
Assigned To:	administrator	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:	5.40
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	MIME type for .nef needs to be image/x-nikon-nef
Description:	MIME type for .nef files is "image/tiff" but it needs to be "image/x-nikon-nef". Mimetype from perl-file-mimeinfo shows it right. file --mime-type /tmp/DSC_1234.nef /tmp/DSC_1234.nef: image/tiff mimetype /tmp/DSC_1234.nef /tmp/DSC_1234.nef: image/x-nikon-nef
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003614) administrator    2021-06-30 09:46	Do you have an example .nef file I can test with?
(0003629) DaarkWel    2021-07-14 08:24	Sorry for delay. Yes. https://mega.nz/file/4MsXkKJJ#kH1v5XHPXkWReCJBFFh-RKJW_1aTGCVm9N6wpAFZkbY
(0003640) maxicarlos0    2021-08-30 11:42	Same issue here, this causes a lot if image viewing programs to fail opening raw images (NEF, ARW tested)
(0003674) Tamaranch    2021-11-14 12:20	Attached is another example of a NEF file recognized as TIFF. It comes from https://filesamples.com/categories/image where you can also find examples of PEF and DNG files recognized as TIFF.
(0003675) Tamaranch    2021-11-14 12:21	Not possible to attach the file in fact: too big.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
298	[file] General	minor	always	2021-11-08 07:53	2021-11-14 12:12
Reporter:	Tamaranch	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.41
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	SVGZ compressed image files created by Inkscape are identified as application/gzip
Description:	Inkscape can create two types of SVGZ formats: lossy and lossless. Both are identified by `file` or `magic_file()` as application/gzip, while a library like librsvg is able to recognize them and allow their loading via gdk-pixbuf.
Tags:	magic
Steps To Reproduce:	Open an SVG image file in Inkscape and save it as SVGZ.
Additional Information:
Attached Files:	splash_inkscape.svgz (4,838 bytes) 2021-11-13 18:22 https://bugs.astron.com/file_download.php?file_id=246&type=bug splash_inkscape_simple.svgz (4,510 bytes) 2021-11-13 18:22 https://bugs.astron.com/file_download.php?file_id=247&type=bug org.xfce.mousepad.svg (98,088 bytes) 2021-11-13 18:22 https://bugs.astron.com/file_download.php?file_id=239&type=bug org.xfce.mousepad_inkscape.svgz (9,394 bytes) 2021-11-13 18:22 https://bugs.astron.com/file_download.php?file_id=240&type=bug org.xfce.mousepad_inkscape_simple.svgz (8,650 bytes) 2021-11-13 18:22 https://bugs.astron.com/file_download.php?file_id=241&type=bug org.xfce.ristretto.svg (30,221 bytes) 2021-11-13 18:22 https://bugs.astron.com/file_download.php?file_id=242&type=bug org.xfce.ristretto_inkscape.svgz (5,246 bytes) 2021-11-13 18:22 https://bugs.astron.com/file_download.php?file_id=243&type=bug org.xfce.ristretto_inkscape_simple.svgz (4,530 bytes) 2021-11-13 18:22 https://bugs.astron.com/file_download.php?file_id=244&type=bug splash.svg (11,867 bytes) 2021-11-13 18:22 https://bugs.astron.com/file_download.php?file_id=245&type=bug

Notes
(0003669) christos    2021-11-13 17:49	Can you please attach a couple of sample files?
(0003670) Tamaranch    2021-11-13 18:22	Here are three file: original (*.svg), Inkscape lossly (*_inkscape_simple.svgz), Inkscape lossless (*_inkscape.svgz).
(0003671) christos    2021-11-14 01:08	Thanks, these are just compressed files; use file -z to see what's inside.
(0003672) Tamaranch    2021-11-14 11:38	Oh right, and so the `MAGIC_COMPRESS` flag for libmagic. I was misled by the fact that the .svgz (or .svg.gz) files produced by `convert file.svg file.svgz` were recognized directly. But they are actually still SVG files in this case, unlike the files linked here. I'll try to push my tests a bit further and read the documentation better before reporting a bug next time, sorry ^^'. Thanks!
(0003673) christos    2021-11-14 12:12	No fix necessary, files are just compressed.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
286	[file] General	minor	always	2021-09-04 15:53	2021-11-14 11:57
Reporter:	maxicarlos0	Platform:	64 Bit
Assigned To:	christos	OS:	Arch Linux
Priority:	normal	OS Version:	up to date
Status:	resolved	Product Version:	5.40
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	MIME of raw images detected as image/tiff
Description:	Recently, `file` started to detect raw images (NEF and ARW tested) as image/tiff. This breaks a lot of image viewing programs such as Gwenview, lximage, Okular, and many more. This wasn't like that always, I remember being able to correctly detect raw images a month ago or so. Thanks in advance.
Tags:
Steps To Reproduce:	Get a raw image (eg. http://www.luminescentphoto.com/nx2/nefs.html) run `file RAW_IMAGE` or `file --mime-type RAW_IMAGE` The output will say that it's a image/tiff image when it should be image/x-nikon-nef
Additional Information:	`mimetype` recognizes the MIME correctly...
System Description
Attached Files:

Notes
(0003643) christos    2021-09-11 19:33	I don't think that file(1) ever reported anything else but tiff for these files. They are tiff files after all...
(0003644) maxicarlos0    2021-09-11 20:48	you might be right, I just checked and the last time file got updated was something around May, way before this problem started happening (in KDE)
(0003653) christos    2021-10-28 15:33	Feedback timeout.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
299	[file] General	minor	always	2021-11-12 08:24	2021-11-13 17:48
Reporter:	adepasquale	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.41
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.42
		Target Version:
Summary:	Separate magic for uuencode and xxencode
Description:	Current file 5.41 doesn't distinguish between uuencode and xxencode. I have updated the magic files based on existing comments, see attached patch. Note that some archivers (e.g. https://wiki.powerarchiver.com/en:help:main:tools:uuencode_xxencode_mime_base64_yenc) do not have the "begin " keyword at zero, so I had to use a regex/1024.
Tags:	magic
Steps To Reproduce:
Additional Information:
Attached Files:	uuencode.patch (1,276 bytes) 2021-11-12 08:24 https://bugs.astron.com/file_download.php?file_id=238&type=bug

Notes
(0003668) christos    2021-11-13 17:48	Applied, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
292	[file] General	minor	always	2021-10-18 11:00	2021-10-28 16:41
Reporter:	mikewalrus	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.40
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	HTML files with LaTeX keywords are identified as LaTeX files.
Description:	An HTML file containing magic entries like `\begin' is identified as a "LaTeX document".
Tags:	magic
Steps To Reproduce:	Save the following to a.html, and run file on it. <!doctype html> <html> <head> <title>title</title> </head> <body> \begin{a} </body> </html>
Additional Information:
Attached Files:

Notes
(0003666) christos    2021-10-28 16:41	Bumped the strength of HTML to beat LaTeX, but it is unclear if this is a win considering the opposite case :-)

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
296	[file] General	major	always	2021-10-24 10:21	2021-10-28 16:39
Reporter:	eliz	Platform:	MinGW
Assigned To:	christos	OS:	MS-Windows
Priority:	normal	OS Version:	XPSP3
Status:	assigned	Product Version:	5.40
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Problems building file-5.41 with MinGW on MS-Windows
Description:	I've built the latest version 5.41 of file natively on MS-Windows using MinGW tools. (Yes, version 5.41; the bug tracker doesn't allow to select that version when reporting an issue.) I've found several problems while building, described below. Let me know if you want me to attach proposed patches for any of those. First, there are multiple compilation warnings due to C99 formatted output features, like the '#' flag and the %z or %j descriptors. (file.h has portability macros for taking care of that, but they are not used everywhere, and don't cover the '#' flag, for example.) Next, compress.c triggers several warnings because variables and functions used only if HAVE_FORK are declared or defined without that conditional, so they are unused in a build without HAVE_FORK. The function 'sread' uses 'ioctl' for sockets and pipes, but that cannot compile on Windows, and won't work even if tweaked (e.g., 'select' doesn't work on Windows pipes). So this needs to be #ifdef'ed away. Same for calls to 'fcntl' in funcs.c. In magic.c, I added support for the HOME environment variable on MS-Windows. While this variable is not normally set on Windows, many users of ported Unix software have it set, so it is useful to support that. The function 'unreadable_info' in magic.c calls 'access' with X_OK, which doesn't work well, or not at all, on MS-Windows, so I replaced it with a simple test of the file's extension to detect executables based on that. Thanks for developing this package.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	DIFFS.mingw (12,033 bytes) 2021-10-28 16:39 https://bugs.astron.com/file_download.php?file_id=237&type=bug

Notes
(0003657) christos    2021-10-28 15:36	Sure, please send patches.
(0003665) eliz    2021-10-28 16:39	I attach patches for MinGW-related issues.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
297	[file] General	major	always	2021-10-24 13:52	2021-10-28 16:34
Reporter:	eliz	Platform:	MinGW
Assigned To:	christos	OS:	MS-Windows
Priority:	normal	OS Version:	XPSP3
Status:	assigned	Product Version:	5.40
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Looking inside compressed files disabled in builds which don't define HAVE_FORK
Description:	Building version 5.41 on a system that doesn't have 'fork' disables built-in support for accessing compressed files, even if decompression libraries (zlib, liblzma, etc.) are available and enabled during configure run. For example 'file_zmagic' isn't even called if HAVE_FORK is not defined to a non-zero value. I've reshuffled the various #define's and made some minor changes to the code to enable built-in decompression support when HAVE_FORK is not available. let me know if you are interested in the patch to do that.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	DIFFS.fork (6,155 bytes) 2021-10-28 16:34 https://bugs.astron.com/file_download.php?file_id=236&type=bug

Notes
(0003651) christos    2021-10-28 15:31	Sure, please send me the patch.
(0003663) eliz    2021-10-28 16:34	I attach the patches for the 'fork' problem.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
295	[file] General	minor	always	2021-10-23 17:31	2021-10-28 16:20
Reporter:	eliz	Platform:	MS-Windows
Assigned To:	christos	OS:	XP
Priority:	normal	OS Version:	SP3
Status:	assigned	Product Version:	5.41
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	pgp-binary-key-v4-dsa test fails due to incorrect expected result
Description:	This test fails:      Running test: ../tests/pgp-binary-key-v4-dsa.testfile      ../tests/pgp-binary-key-v4-dsa.testfile: OpenPGP Public Key Version 4, Created Mon Apr 07 22:23:01 1997, DSA (1024 bits); User ID; Signature; OpenPGP Certificate      test.exe: ERROR: result was (len 120)      OpenPGP Public Key Version 4, Created Mon Apr 07 22:23:01 1997, DSA (1024 bits); User ID; Signature; OpenPGP Certificate      expected (len 121) This is because the expected result says "Mon Apr 7" instead of "Mon Apr 07" (2 spaces instead of a space an zero). Correcting the expected result makes the test succeed.
Tags:
Steps To Reproduce:	make check
Additional Information:
Attached Files:

Notes
(0003650) eliz    2021-10-24 05:56	By the way, this is for version 5.41, not 5.40; but the bug tracker doesn't allow to select 5.41 as the version for the bug.
(0003658) christos    2021-10-28 15:43	Your libc is broken: file(1) just uses ctime/asctime: https://pubs.opengroup.org/onlinepubs/9699919799/
(0003659) christos    2021-10-28 15:47	Added 5.41 to the list of releases.
(0003662) eliz    2021-10-28 16:20	That broken libc is MSVCRT. the C runtime used by MinGW builds on MS-Windows. So I guess this means that test will fail for any MinGW build, unless the expected results are manually "fixed".

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
294	[file] General	feature	always	2021-10-21 21:06	2021-10-28 15:53
Reporter:	Jamie	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.40
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.42
		Target Version:
Summary:	Magic bytes c64 .dfi format
Description:	Hello everyone, attached is a patch for recognizing the c64 .dfi file format. Currently such files are reported as data:     $ file --version     file-5.40     magic file from /usr/share/file/misc/magic     seccomp support included     $ file --keep-going 10_Years_HVSC.dfi     10_Years_HVSC.dfi: data I got the structure from https://www.lemon64.com/forum/viewtopic.php?t=37415&sid=494dc2ca91289e05dadf80a7f8a968fe (at the bottom). More general information about the format can be found at https://www.c64-wiki.com/wiki/DreamLoad. An example file can be found in the HVSC Commodore 64 music collection, for example at https://kohina.duckdns.org/HVSC/C64Music/10_Years_HVSC.dfi. Do you think it makes sense to include this? Best, Jamie
Tags:	magic
Steps To Reproduce:
Additional Information:
Attached Files:	c64.patch (476 bytes) 2021-10-21 21:06 https://bugs.astron.com/file_download.php?file_id=235&type=bug

Notes
(0003649) Jamie    2021-10-21 21:09	With the patch applied, the output is as follows:     $ file --magic-file tmp.magic 10_Years_HVSC.dfi     10_Years_HVSC.dfi: DFI Image version: 1.0 tracks: 4
(0003661) christos    2021-10-28 15:53	Added!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
290	[file] General	minor	always	2021-09-20 13:34	2021-10-28 15:32
Reporter:	ChaoticRoman	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.40
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Wrong installation instructions in both INSTALL and README.DEVELOPER files
Description:	In the INSTALL, there are generic "./configure; make; make install" instructions but it seems that correct process is autoreconf -f -i ./configure --disable-silent-rules make make install In the README.DEVELOPER, there is     autoreconf -f -i     make distclean     ./configure --disable-silent-rules     make -j4     make -C tests check but "make distclean" would complain "make: *** No rule to make target distclean'". Tested on Ubuntu 20.04 by myself. Original report: https://stackoverflow.com/questions/69222631/46-regex-error-17-for-dryad-bibo-v0-9-0-9-match-failed
Tags:
Steps To Reproduce:	./configure autoreconf -f -i make distclean
Additional Information:
Attached Files:

Notes
(0003645) christos    2021-09-20 14:05	I added a comment that it can fail in README.DEVELOPER. The INSTALL file is fine because it instructs you to use 'make distclean' to cleanup after a previous build.
(0003652) christos    2021-10-28 15:32	Feedback timeout.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
288	[file] General	minor	always	2021-09-13 07:18	2021-09-20 17:46
Reporter:	Cirn09	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.41
		Target Version:
Summary:	Naming conflict when compiling libmagic as Windows static library
Description:	hello, I want build `libmagic` as static library for Windows. But `libmagic` define the `DllMain` in `magic.c`: ``` /* Placate GCC by offering a sacrificial previous prototype */ BOOL WINAPI DllMain(HINSTANCE, DWORD, LPVOID); BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason,     LPVOID lpvReserved __attribute__((__unused__))) {     if (fdwReason == DLL_PROCESS_ATTACH)         _w32_dll_instance = hinstDLL;     return 1; } ``` This causes naming conflicts when linking libmagic to a dynamic library: > `libmagic.lib(magic.obj) : error LNK2005: DllMain already defined in dllmain.obj` `DllMain` is only used to initialize `_w32_dll_instance`. In fact, for static libraries, `_w32_dll_instance` is not needed. `_w32_dll_instance` only used in `get_default_magic` ``` private const char * get_default_magic(void) { ...     /* Fourth, try to get magic file relative to exe location */         _w32_get_magic_relative_to(&hmagicpath, NULL);     /* Fifth, try to get magic file relative to dll location */         _w32_get_magic_relative_to(&hmagicpath, _w32_dll_instance);     /* Fifth, try to get magic file relative to dll location */         _w32_get_magic_relative_to(&hmagicpath, _w32_dll_instance); ... static void _w32_get_magic_relative_to(char **hmagicpath, HINSTANCE module) { ...     if (!GetModuleFileNameA(module, dllpath, MAX_PATH)) ... ``` > Parameters > hModule > A handle to the loaded module whose path is being requested. If this parameter is **NULL**, > GetModuleFileName retrieves the path of the executable file of the current process. > https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-getmodulefilenamea I think to solve this problem need to add a new macro judgment, like: ``` #ifndef BUILD_AS_WINDOWS_STATIC_LIBARAY BOOL WINAPI DllMain(HINSTANCE, DWORD, LPVOID) ... #endif ```
Tags:	build
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003646) christos    2021-09-20 17:46	Added as suggested, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
287	[file] General	minor	always	2021-09-09 17:23	2021-09-11 19:20
Reporter:	alealbonico	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.40
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.41
		Target Version:
Summary:	MIME of message/rfc822 detected as text/plain
Description:	Email files with MIME message/rfc822 are being detected as text/plain because said file's header starts with "Date:" instead of "From:" or "Received:". I checked the documentation for the standard way to write a rfc822 message and it looks like date is actually allowed to be on the first line, too. Thanks in advance.
Tags:
Steps To Reproduce:	Get a rfc822 file and place the header date as the first line in it. Example of file: ------- Date: Fri, 07 Aug 2020 02:09:32 +0100 From: "xxxx" <xxxx@gmail.com> To: "yyyy" <yyyy@gmail.com> Subject: zzzzzzzz MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--464994466596adLKMdfn3566452152" X-Rejection-Reason: zzzzzz ----464994466596adLKMdfn3566452152 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable [redacted] ----464994466596adLKMdfn3566452152 Content-Type: application/msword; name="xxxx" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="xxxx" xyz ----464994466596adLKMdfn3566452152-- ------- Try to get the MIME type. Output: text/plain Notice that removing date and leaving "from" on top instead will return the correct output.
Additional Information:
Attached Files:

Notes
(0003642) christos    2021-09-11 19:20	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
285	[file] General	block	always	2021-08-26 09:25	2021-09-09 17:49
Reporter:	Benjamin	Platform:	Linux
Assigned To:	christos	OS:	Ubuntu
Priority:	normal	OS Version:	Ubuntu 18.04.5
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.41
		Target Version:
Summary:	Python biding of libmagic crash when trying to detect encoding in multithread
Description:	Hello, When i use the following code in a multithreaded environment (some django workers using Huey or Dramatiq) magic.detect_from_content(             bytes_file.read(MAX_BYTES)         ).encoding I got some:   File "/home/benjamin/.cache/pypoetry/virtualenvs/qvNem8AN-py3.9/lib/python3.9/site-packages/magic.py", line 284, in detect_from_content     return _create_filemagic(mime_magic.buffer(byte_content),   File "/home/benjamin/.cache/pypoetry/virtualenvs/qvNem8AN-py3.9/lib/python3.9/site-packages/magic.py", line 251, in _create_filemagic     mime_type, mime_encoding = mime_detected.split('; ') ValueError: too many values to unpack (expected 2) With the reproductible code given in this ticket errors can be differents ("munmap_chunk(): invalid pointer", "free(): invalid size", "double free or corruption (fasttop)") It works correctly on a single thread.
Tags:	magic
Steps To Reproduce:	import threading import magic MAX_BYTES = 4096 def thread_function():     with open("/tmp/foo.csv", "rb") as bytes_file:         print(magic.detect_from_content(             bytes_file.read(MAX_BYTES)         ).encoding) if __name__ == '__main__':     threads = list()     for index in range(3):         thread = threading.Thread(target=thread_function)         threads.append(thread)         thread.start()     for index, thread in enumerate(threads):         thread.join()
Additional Information:	My ubuntu libmagic1 version is: 1:5.32-2ubuntu0.4 My file-magic python packaque is 0.4.0
Attached Files:

Notes
(0003641) christos    2021-09-09 17:49	Thanks, fixed in HEAD. Will release as 0.4.1 when I release the next version of file(1).

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
284	[file] General	feature	always	2021-08-18 23:35	2021-08-24 09:25
Reporter:	ntavares	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.40
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.41
		Target Version:
Summary:	New file format - SER video sequence
Description:	Hi there, I found it strange that there was no magic for SER files, please add it. This is a very popular video format among astrophotographers. It's a video file, so I'm not attaching a sample. I could provide the header from a real file, though, if it's useful. Just let me know. -NT
Tags:
Steps To Reproduce:	# SER file format - simple uncompressed video format for astronomical use # Initially developed by Lucam Recorder, as of 2021 maintained by Heiko Wilkens, Grischa Hahn # Typical extensions: .SER # V3 - http://www.grischa-hahn.homepage.t-online.de/astro/ser/SER%20Doc%20V3b.pdf 0 string LUCAM-RECORDER SER video sequence >18 lelong 0 \b, bayer: mono >18 lelong 8 \b, bayer: RGGB >18 lelong 9 \b, bayer: GRBG >18 lelong 10 \b, bayer: GBRG >18 lelong 11 \b, bayer: BGGR >18 lelong 16 \b, bayer: CYYM >18 lelong 17 \b, bayer: YCMY >18 lelong 18 \b, bayer: YMCY >18 lelong 19 \b, bayer: MYYC >18 lelong 100 \b, bayer: RGB >18 lelong 101 \b, bayer: BGR >22 lelong 0 \b, big-endian >22 lelong 1 \b, little-endian >26 lelong x \b, width: %d >30 lelong x \b, height: %d >34 lelong x \b, %d bit >38 lelong x \b, frames: %d
Additional Information:
Attached Files:

Notes
(0003639) christos    2021-08-24 09:25	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
281	[file] General	trivial	always	2021-08-11 16:08	2021-08-16 10:20
Reporter:	pwinckles	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.41
		Target Version:
Summary:	epub files report duplicate format names
Description:	When you execute file on an epub file the output contains a duplicate format name: EPUB document EPUB document
Tags:
Steps To Reproduce:	1. Get an epub file (example: https://github.com/openpreserve/format-corpus/blob/master/ebooks/calibre%200.9.0/lorem-ipsum.epub) 2. Execute file on the file 3. See output like: lorem-ipsum.epub: EPUB document EPUB document
Additional Information:
Attached Files:

Notes
(0003637) christos    2021-08-16 10:20	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
279	[file] General	major	always	2021-08-05 03:20	2021-08-16 10:13
Reporter:	Jayc3Ca0	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.40
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.41
		Target Version:
Summary:	Java source code is reported as C source file
Description:	Java source code file is reported as C source file by file command.
Tags:	magic
Steps To Reproduce:	Write the following Java sample code (TestJava.java): public class TestJava {     public static void main(String[] args) {         System.out.println("Hello Java");     } } Use file command of the latest version to check its type: $ file TestJava.java TestJava.java: C source, ASCII text
Additional Information:	Tested on macOS 11.3.1 with version 5.40, which is installed by homebrew. Also tested on CentOS 7 with version 5.11.37, which is installed by yum.
Attached Files:

Notes
(0003636) christos    2021-08-16 10:13	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
280	[file] General	trivial	always	2021-08-09 21:55	2021-08-16 10:07
Reporter:	rouca	Platform:
Assigned To:	christos	OS:
Priority:	low	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.41
		Target Version:
Summary:	Detect silverlight
Description:	Hi, Just send a mail to mailing list copy paste here: In order to remove problematic source from debian we want to detect silverlight compiled program Some example: http://cespage.com/silverlight/tutorials/sl4tut1.xap https://www.microsoft.com/silverlight/new-controls/demo/System.Windows.Controls.Samples.xap It seems that AppManifest.xaml string is present in the zip file (uncompressed)... Thanks Bastien
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003635) christos    2021-08-16 10:07	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
277	[file] General	feature	N/A	2021-07-26 18:07	2021-07-30 12:25
Reporter:	polluks	Platform:	PowerBook5,8
Assigned To:	christos	OS:	MorphOS
Priority:	normal	OS Version:	3.15
Status:	resolved	Product Version:	5.40
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.41
		Target Version:
Summary:	More Plan 9
Description:	Added object files
Tags:	magic
Steps To Reproduce:
Additional Information:
System Description
Attached Files:	plan9 (1,146 bytes) 2021-07-26 18:07 https://bugs.astron.com/file_download.php?file_id=233&type=bug

Notes
(0003632) christos    2021-07-30 12:25	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
275	[file] General	minor	always	2021-07-19 13:50	2021-07-30 11:47
Reporter:	pwinckles	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.41
		Target Version:
Summary:	PDFs with /Filter/FlateDecode streams are incorrectly marked as "password protected"
Description:	This commit[1] introduces a change that appears to label PDFs containing /Filter/FlateDecode streams as "password protected". I'm no PDF expert, but this designation seems incorrect as it just indicates that the stream is compressed. It may or may not be encrypted. [1] https://github.com/file/file/commit/629972a91e05fcad8a1b5d906344838539b5f7ab#diff-1d80c89187edc2a2fab5b3ef59fadc199e03d7c8319e7e41e2bd1f329c00fee7
Tags:
Steps To Reproduce:	1. Download the following example PDF: https://github.com/harvard-lts/fits/blob/dev/testfiles/PDF_embedded_resources.pdf 2. Execute: file PDF_embedded_resources.pdf 3. See the following output, even though the file is not password protected: PDF_embedded_resources.pdf: PDF document, version 1.6 (password protected)
Additional Information:
Attached Files:

Notes
(0003631) christos    2021-07-30 11:47	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
239	[file] General	feature	N/A	2021-02-18 22:57	2021-07-27 22:20
Reporter:	polluks	Platform:	PowerBook5,8
Assigned To:	christos	OS:	MorphOS
Priority:	normal	OS Version:	3.15
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	More IFF magic again
Description:	--- iff.bak 2020-10-27 00:41:15 +0100 +++ iff 2021-02-18 22:41:57 +0100 @@ -44,6 +44,7 @@  >8 string FANT \b, Fantavision animation  >8 string ACBM \b, ACBM continuous image  >8 string FAXX \b, FAXX fax image +>8 string STFX \b, ST-Fax image  # other formats  >8 string FTXT \b, FTXT formatted text  >8 string CTLG \b, CTLG message catalog
Tags:	magic
Steps To Reproduce:
Additional Information:
System Description
Attached Files:

Notes
(0003554) polluks    2021-02-20 17:34	Update --- iff.bak 2020-10-27 00:41:15 +0100 +++ iff 2021-02-20 18:28:42 +0100 @@ -44,6 +44,7 @@  >8 string FANT \b, Fantavision animation  >8 string ACBM \b, ACBM continuous image  >8 string FAXX \b, FAXX fax image +>8 string STFX \b, ST-Fax image  # other formats  >8 string FTXT \b, FTXT formatted text  >8 string CTLG \b, CTLG message catalog @@ -54,6 +55,7 @@  >8 string WZRD \b, WZRD StormWIZARD resource  >8 string DOC\ \b, DOC desktop publishing document  >8 string SWRT \b, SWRT Final Copy/Writer document +>8 string WORD \b, ProWrite document  >8 string WTXT \b, WTXT Wordworth document  >8 string WOWO \b, WOWO Wordworth document  >8 string WVQA \b, Westwood Studios VQA Multimedia,
(0003556) christos    2021-02-23 01:07	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
274	[tcsh] General	minor	always	2021-07-09 12:04	2021-07-09 16:10
Reporter:	polarnik	Platform:
Assigned To:	christos	OS:
Priority:	low	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	6.23.00
		Target Version:
Summary:	Regression: slashes dropped on directory tab completion
Description:	A commit on 2021-07-05 introduced a regression, in that terminal slashes are now dropped on directory tab completion.
Tags:
Steps To Reproduce:	$ cd /bin/<tab> expected: dir1/ dir2/ ... actual: dir1 dir2
Additional Information:	The last known working version is ed9ba69fe360d5b1110e4b1e71995ccf3eb72925. The regression was introduced by one of two commits on 2021-07-05: b5160d8de71e29c7cfa29efd26bcf149863ac544 -or- 9ad196ca789236217a9d7d330bc08a4e0b38bd57 ---------- A subset of my settings: set autoexpand set autolist set filec complete cd 'p/1/d/'
Attached Files:

Notes
(0003627) polarnik    2021-07-09 12:08	Minor correction: in steps to repro, it should have been a directory with subdirs: e.g. cd /<tab>
(0003628) christos    2021-07-09 16:10	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
273	[file] General	minor	have not tried	2021-07-04 18:25	2021-07-05 11:56
Reporter:	timothee	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.41
		Target Version:
Summary:	nim files reported as ASCII text
Description:	nim files reported as ASCII text eg: this file https://github.com/nim-lang/Nim/blob/devel/koch.nim should be reported as nim program text, ASCII text instead of: ASCII text
Tags:
Steps To Reproduce:	create a file koch.nim with a nim extension (or download https://github.com/nim-lang/Nim/blob/devel/koch.nim) type `file koch.nim` shows: koch.nim: ASCII text
Additional Information:
Attached Files:

Notes
(0003625) christos    2021-07-05 09:49	Committed some magic.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
258	[tcsh] General	feature	always	2021-04-10 17:08	2021-07-05 10:41
Reporter:	ajr	Platform:	Mac
Assigned To:	christos	OS:	macOS Big Sur
Priority:	normal	OS Version:	11.2.3
Status:	resolved	Product Version:	6.22.03
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	6.23.00
		Target Version:
Summary:	ls-F and file expansion do not support 'ln=target' in LS_COLORS
Description:	GNU ls and bash allow for 'ln=target' in LS_COLORS. This sets the color to that of the file pointed to while maintaining the '@' suffix. In tcsh it comes out as "argetm" since it assembles the color string as "\e[targetm". Changes to tw.decls.h, tw.color.c, and tw.parse.c (attached) implements support for ln=target
Tags:
Steps To Reproduce:
Additional Information:	Diffs can be seen at https://github.com/ajrosen/tcsh/commit/b516f30f4849267a1e953c4f3fa613805415bf82
Attached Files:	tw.color.c (13,267 bytes) 2021-04-10 17:08 https://bugs.astron.com/file_download.php?file_id=217&type=bug tw.decls.h (5,030 bytes) 2021-04-10 17:08 https://bugs.astron.com/file_download.php?file_id=218&type=bug tw.parse.c (58,277 bytes) 2021-04-10 17:08 https://bugs.astron.com/file_download.php?file_id=219&type=bug

Notes
(0003626) christos    2021-07-05 10:41	committed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
272	[file] General	minor	always	2021-06-28 09:27	2021-07-01 07:52
Reporter:	kiefermat	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.40
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.41
		Target Version:
Summary:	Missing separator in multiple mimetypes for some files
Description:	When getting the mimetype of an mp3 file (e.g. https://filesamples.com/samples/audio/mp3/sample1.mp3) using the -k flag ("file -k --mime-type sample1.mp3"), file 5.40 reports the following mimetype: audio/mpegapplication/octet-stream Version 5.39 reports it as audio/mpeg - application/octet-stream
Tags:
Steps To Reproduce:	file -k --mime-type sample1.mp3
Additional Information:
Attached Files:

Notes
(0003623) christos    2021-07-01 07:52	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
268	[file] General	feature	N/A	2021-06-03 12:04	2021-06-30 12:01
Reporter:	benedikt	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	reopened
Projection:	none
ETA:	none	Fixed in Version:	5.41
		Target Version:
Summary:	Magic number and MIME type registration for Resilient Logic
Description:	To whom I may concern, I have just registered the MIME-type application/vnd.resilient.logic for my company. The official entry at IANA can be found here: https://www.iana.org/assignments/media-types/application/vnd.resilient.logic I'd like to have it included in the list of magic numbers that file includes. The magic number sequence of this file format is 0x07, 0x52, 0x4c, 0x4d. Best regards, Benedikt Muessig Resilient TechEd GmbH
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	resilient_logic_test.rlm (87 bytes) 2021-06-30 10:40 https://bugs.astron.com/file_download.php?file_id=230&type=bug

Notes
(0003617) christos    2021-06-30 10:23	Thanks, added magic, but without an example file, I can't test.
(0003619) benedikt    2021-06-30 10:39	Hello Christos, thank you for taking care of adding the magic number. I am sorry for not providing you with an example file. I've just uploaded one here: https://c.gmx.net/@702592736817053755/K7lhZLD2Rqujc5BS-bbm0w Best regards, Benedikt
(0003620) benedikt    2021-06-30 10:40	For some reason the file upload section did not show up earlier. This is a re-upload of the other file. BR, Benedikt
(0003621) benedikt    2021-06-30 11:37	I've got two more questions, if you don't mind: In the updated mime file, it says ">4 beshort x \b, version %d". I suppose that beshort means 16 bit, big endian. The file version though is just one 8-bit byte, where the high 4 bits are the major and the low 4 bits the minor version. The other question is, if it is possible to add the mime-type, so that it works with `file --mime-type`? Best regards and thanks, Benedikt
(0003622) christos    2021-06-30 12:01	Should be all better now.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
267	[file] General	major	always	2021-05-31 17:15	2021-06-30 10:25
Reporter:	xexaxo	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.40
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.41
		Target Version:
Summary:	File detects CPIO files as "application/octet-stream"
Description:	Using --mime with CPIO files made by bsdtar, seems to detected incorrectly. In particular:  file --mime foo.cpio  foo.cpio: application/octet-stream; charset=binary On the other hand, when omitting the --mime it is detected properly:  file foo.cpio  foo.cpio: ASCII cpio archive (SVR4 with no CRC) The file foo.cpio was created using the following:  echo test > test-file  LANG=C bsdtar --uid 0 --gid 0 --null -cf - --format=newc test-file > foo.cpio
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003609) xexaxo    2021-05-31 17:19	In case it matters, xdg-mime correctly detects the file:  xdg-mime query filetype foo.cpio  application/x-cpio
(0003610) polluks    2021-06-03 21:45	--- archive.bak 2021-04-26 09:54:42 +0200 +++ archive 2021-06-03 23:43:29 +0200 @@ -169,6 +169,7 @@  !:mime application/x-cpio # encoding: swapped  0 string 070707 ASCII cpio archive (pre-SVR4 or odc)  0 string 070701 ASCII cpio archive (SVR4 with no CRC) +!:mime application/x-cpio  0 string 070702 ASCII cpio archive (SVR4 with CRC)    #
(0003611) xexaxo    2021-06-04 15:10	Thanks polluks - your suggestion works like a charm. Now if I can figure out how this fix can get merged into the official tree...
(0003618) christos    2021-06-30 10:25	Fixed, thanks

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
269	[file] General	crash	always	2021-06-07 16:40	2021-06-30 10:12
Reporter:	roneyth	Platform:
Assigned To:	christos	OS:
Priority:	high	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.41
		Target Version:
Summary:	Undefined Behavior: applying zero offset to null pointer
Description:	Enabling Undefined Behavior Sanitizer (UBSAN) check for pointer overflow(-fsanitize=pointer-overflow) causes the below error to be detected in file/src/apprentice.c. /src/apprentice.c:567:43: runtime error: applying zero offset to null pointer     #0 0x7f9c571ef541 in apprentice_unmap src/apprentice.c:567:43     0000001 0x7f9c571ef34b in mlist_free_one src/apprentice.c:611:3     0000002 0x7f9c571ed261 in mlist_free src/apprentice.c:625:3     0000003 0x7f9c571ed147 in file_ms_free src/apprentice.c:504:3     0000004 0x7f9c572172ae in magic_close src/magic.c:291:2     0000005 0x2f16d5 in main tests/test.c     0000006 0x7f9c56008674 in __libc_start_main libc-start.c     0000007 0x24aeb8 in _start elfstart.S The code where error observed                      CAST(char *, b) <= CAST(char *, p) + map->len)
Tags:
Steps To Reproduce:	clang++ -fsanitize=pointer-overflow sourcefile
Additional Information:	FWIW. we have thought of a fix as : CAST(char *, b) <= (p ? CAST(char *, p) + map->len : CAST(char *, map->len))) I wonder if there isn't a more elegant solution . Please do check the issue and make a fix ASAP.
Attached Files:

Notes
(0003616) christos    2021-06-30 10:12	Fixed, thanks.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
270	[file] General	trivial	always	2021-06-08 03:41	2021-06-30 10:09
Reporter:	ContronThePanda	Platform:
Assigned To:	christos	OS:
Priority:	low	OS Version:
Status:	resolved	Product Version:	5.40
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.41
		Target Version:
Summary:	When printing with %c from magic file, some characters are still escaped as \ooo in output even with -r option
Description:	Basically exactly what the title says, I came across this while trying to see if I could use a custom magic file to print a terminal bell. However, even if I pass the -r flag, file still escapes the terminal bell as \007 as long as I print it using %s. It's worth noting that it actually prints the bell character when I use the %c pattern. This only applies to %s, for some reason.
Tags:	magic
Steps To Reproduce:	I've attached both the custom magic file and a file containing a bell character to test it on. You can reproduce this by running `file -rm bell-magic bell-file`.
Additional Information:
Attached Files:	bell-file (2 bytes) 2021-06-08 03:41 https://bugs.astron.com/file_download.php?file_id=226&type=bug bell-magic (15 bytes) 2021-06-08 03:41 https://bugs.astron.com/file_download.php?file_id=227&type=bug

Notes
(0003615) christos    2021-06-30 10:09	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
266	[file] General	minor	always	2021-05-20 22:01	2021-06-08 18:13
Reporter:	j2j	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:	5.40
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	False hits by Magdir/pgp-binary-keys
Description:	when i run file command version 5.40 on some files with -k option i often get also misidentification messages starting with "OpenPGP". See appended output OpenPGP-bad-k.txt. When looking inside sources i see that such messages are triggered by magic lines inside Magdir/pgp-binary-keys. These magic lines should identify OpenPGP files. The above mentioned examples are handled by starting lines like  0 ubyte&0xFC =0x94 OpenPGP Secret Key  >&-1 use primary_key_length_old After inspecting just one byte print a message starting with "OpenPGP Secret Key" and then do some additional check by calling sub routine like primary_key_length_old. Obviously checking only 1 byte is not sufficient. So non PGP examples with starting byte 95h like mathemusic, PEDE and samples starting with 97h like Event.Tdf, RIRE6.SPL, Rx.GS and Welcome.Snd are misidentified. The consistence check is done later by sub routine pgp_binary_key_pk_check which checks for valid versions range (2-7) and valid time stamps (after 1990). The correct way would be to check some possible PGP packets for valid version and time stamp. If this succeeds then afterwards display some message text. Furthermore the samples starting with 97h are also described inside Magdir/pgp in a more unreliable way by line starting with  0 byte 0x97 PGP Secret Sub-key - So when check and describing part is done by Magdir/pgp-binary-keys then remove the lines from Magdir/pgp. Furthermore with --extension option the 31 byte string pgp/gpg/pkr/asd is shown. For public "foo" extension pkr is used whereas for secret "foo" the extension "skr" is used. So skr file is missing in the following magic line: !:ext pgp/gpg/pkr/asd And when doing effort in inspecting PGP packet for "OpenPGP Public Key" and "OpenPGP Secret Key" then it would be a good thing to display afterwards the right file name extension ( pkr or skr). Furthermore the extension asd is listed as a possibility. As far as i know i no PGP or related file exist with that extension. My misidentified examples are stored in appended archive OpenPGP-bad.zip.
Tags:	PGP
Steps To Reproduce:
Additional Information:
Attached Files:	OpenPGP-bad-k.txt (578 bytes) 2021-05-20 22:01 https://bugs.astron.com/file_download.php?file_id=224&type=bug OpenPGP-bad.zip (66,795 bytes) 2021-05-20 22:01 https://bugs.astron.com/file_download.php?file_id=225&type=bug 0001-Show-information-about-a-PGP-key-only-if-we-have-a-s.patch (2,356 bytes) 2021-06-08 18:12 https://bugs.astron.com/file_download.php?file_id=228&type=bug 0002-For-binary-PGP-keys-only-use-the-pgp-and-gpg-extensi.patch (792 bytes) 2021-06-08 18:12 https://bugs.astron.com/file_download.php?file_id=229&type=bug

Notes
(0003608) neal    2021-05-29 21:27	(I wrote pgp-binary-keys.) Thanks for the thorough report. I tested a lot of true positives (a large portion of the SKS dump), but it seems I failed to test enough false positives. The code checks a lot of bits, so it should be unambiguous. I suspect the problem is that I just emit "OpenPGP Secret Key" too early. As for the file extensions, I'm only aware of .pgp and .gpg. The other variants existed in the old version of the code, so I kept them assuming that they used to be used. I'll take a look in the next few days.
(0003612) neal    2021-06-08 18:12	The issue identifies three problems:   1. Descriptions in pgp-binary-key are printed too eagerly.   2. Descriptions in pgp (PGP Secret Sub-key) are printed too eagerly.   3. The extensions listed in pgp-binary-key are wrong. I've fixed one as j2j suggested. Unfortunately, I can't figure out how to distinguish public and secret keys anymore, because the first byte of the file is not accessible from a function ("use"). The other patch fixes 3. I've changed it to only report pgp and gpg as valid extensions. I've never actually seen srk, prk or adf used in practice and I've been doing PGP stuff for nearly a decade.
(0003613) neal    2021-06-08 18:13	(I'll take a look at pgp and prune the secret subkey detection and some other stuff that is not actually useful in practice.)

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
196	[file] General	minor	have not tried	2020-09-01 14:02	2021-05-29 19:09
Reporter:	neal	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	Improve pgp binary key detection support
Description:	The pgp binary key detection support is broken in numerous ways:   - It only deals with old-style CTBs (new-style CTBs were introduced in RFC 2440 released in 1998)   - It only deals with two byte length encoding. With small keys (thanks to ECC), 1 byte length encoding is typical for new keys.   - It's not terribly robust.   - It prints the MPI prefix, which is completely meaningless to all users (the fingerprint is more interesting, but it is the hash of the public key, which we can't compute using magic). The new version checks more data. It checks that the first three packets are sane before emitting a mime type. And, it standardizes the terminology (PGP/GPG key public ring is... unusual).
Tags:
Steps To Reproduce:	Do test, I downloaded the SKS dump and extracted the first 262753 public keys. $ cd /tmp $ GNUPGHOME=$(mktemp -d) $ for i in `seq 0 100`; do wget https://pgp.key-server.io/dump/current/sks-dump-$(printf %04d $i).pgp; gpg --import sks-dump-$(printf %04d $i).pgp; done $ mkdir /tmp/keys $ gpg -k --with-colons | grep '^pub' | awk -F: '{ print $5 }' | while read k; do gpg --export $k > keys/$k.pgp; done Then I did: ~/src/file$ make && find /tmp/keys/ | xargs src/file -m magic/Magdir/pgp-binary-keys 2>&1 > /tmp/normal-detection.txt; find /tmp/keys/ | xargs src/file --mime-type -m magic/Magdir/pgp-binary-keys 2>&1 > /tmp/mime-detection.txt I did this using the new version and the version installed in Debian. My patched version detects all certificates and correctly prints the mime type for all certificates. The original version misses: 12095 certificates.
Additional Information:
Attached Files:	0006-Improve-detection-of-OpenPGP-binary-keys.patch (49,321 bytes) 2020-09-01 14:02 https://bugs.astron.com/file_download.php?file_id=176&type=bug 0001-Improve-detection-of-OpenPGP-binary-keys.patch (63,243 bytes) 2020-10-14 12:10 https://bugs.astron.com/file_download.php?file_id=184&type=bug

Notes
(0003472) neal    2020-09-01 14:03	Note: this requires the fixes that I submitted to work.
(0003479) christos    2020-09-05 17:27	The pgp-binary-keys file is missing from the patch?
(0003494) neal    2020-10-14 12:10	Sorry about the delay. I've added pgp-binary-keys file.
(0003495) christos    2020-10-14 21:11	Thanks!
(0003607) christos    2021-05-29 19:09	It appears that we mis-identify many files as pgp keys: see https://bugs.astron.com/view.php?id=266. Is there any way to make the detection stronger?

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
264	[file] General	feature	have not tried	2021-05-09 22:47	2021-05-10 01:11
Reporter:	jbosboom	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Magic for Python pickle serialization format
Description:	Pickle is a Python serialization format. Starting with version 2, pickles have a 2-byte protocol header, and starting with version 4, pickles have a frame opcode that provides a length hint (for that frame, not necessarily for the whole pickle). All versions end with a period. Version 0 is an ASCII text format and version 1 adds some binary opcodes, but as neither has a version header, they are not definable with magic. Pickles that have been modified by removing the header/framing or adding trailing garbage can still be deserialized, but are also not definable by magic. 0 string \x80\x02 >-1 byte 0x2e Python pickle data, protocol version 2 0 string \x80\x03 >-1 byte 0x2e Python pickle data, protocol version 3 0 string \x80\x04\x95 >-1 byte 0x2e Python pickle data, protocol version 4 0 string \x80\x05\x95 >-1 byte 0x2e Python pickle data, protocol version 5 Pickle is defined by the reference implementation; see https://docs.python.org/3/library/pickle.html#data-stream-format and the PEPs linked from that section. For testing, https://gist.github.com/jbosboom/1438dcbc304b7325802c36257f5dede9 is a Python script that creates pickles of each version containing the same data. `python -m pickletools <file>` can be used to disassemble a pickle. According to `man magic`, negative offsets (as used in the magic definitions above) can only appear at the top level or as a continuation offset (with &), but this is evidently not a limitation, and in fact my initial attempt to write pickle magic given below does not seem to work: -1 byte 0x2e >0 string \x80\x02 Python pickle data, protocol version 2 >0 string \x80\x03 Python pickle data, protocol version 3 >0 string \x80\x04\x95 Python pickle data, protocol version 4 >0 string \x80\x05\x95 Python pickle data, protocol version 5 You may wish to bring the implementation and the documentation into alignment.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
15	[file] General	feature	N/A	2018-07-24 15:19	2021-05-10 01:09
Reporter:	eschwartz	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.41
		Target Version:
Summary:	Try to acquire the "magic" name on the Python Package Index
Description:	Per https://www.python.org/dev/peps/pep-0541/ an abandoned project can be deleted by the PyPI maintainers to clear the way for reusing the name. The current "magic" package on https://pypi.org/project/magic/ is unmaintained since initial upload in 2003, it cannot even be installed as there is no code uploaded to PyPI, the "Project links: Download" points at a website that no longer exists (according to web.archive.org it disappeared sometime between 20121203 and 20130103), and I cannot find the original uploader on the internet more recently than 2003. I suspect it would not be difficult to convince the PyPI maintainers of the validity of a claim by the official project. :)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000016) christos    2018-07-25 06:55	I'll send mail to jp-py@jsnp.net who owns the project first.
(0000017) christos    2018-07-25 06:59	I've sent mail, waiting for a response.
(0000021) christos    2018-08-01 09:02	Sent mail to infrastructure-stuff@python.org to ask what to do next.
(0000046) christos    2018-08-11 11:27	No answer there, opened: https://github.com/pypa/pypi-legacy/issues/802
(0003421) christos    2020-06-01 19:49	Re-filed under: https://github.com/pypa/pypi-support/issues/429
(0003584) eschwartz    2021-04-14 14:34	The ticket has been processed by PyPI support and transferred over. So this can be closed as implemented.
(0003606) christos    2021-05-10 01:09	We have it now.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
263	[file] General	minor	always	2021-05-02 19:52	2021-05-09 22:39
Reporter:	peoro	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.40
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.41
		Target Version:
Summary:	Shebang patterns only match the beginning of the command, rather than the whole word
Description:	Currently, magic patterns that detect files using a shebang only test the beginning of the command string. A file starting with e.g. `#!/usr/bin/env basher` is detected as "Bourne-Again shell script", even though "basher" is not bash. The same issue affects every shebang pattern I tried (sh, bash, node, python, perl etc).
Tags:
Steps To Reproduce:	$ echo '#!/bin/shawarma' > script $ file script script: POSIX shell script, ASCII text executable
Additional Information:
Attached Files:

Notes
(0003605) christos    2021-05-09 22:39	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
262	[file] General	minor	sometimes	2021-04-27 15:52	2021-04-27 20:36
Reporter:	polluks	Platform:	PowerBook5,8
Assigned To:	christos	OS:	MorphOS
Priority:	normal	OS Version:	3.15
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.41
		Target Version:
Summary:	better sinclair
Description:	--- sinclair.bak 2019-02-22 14:06:34 +0100 +++ sinclair 2021-04-11 02:00:00 +0200 @@ -31,6 +31,8 @@  # Sinclair QL executables (was ThMO)  4 belong 0x4AFB QDOS executable  >9 pstring x '%s' +6 beshort 0x4AFB QDOS executable +>9 pstring x '%s'    # Sinclair QL ROM (ThMO)  0 belong =0x4AFB0001 QL plugin-ROM data,
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:	config (7,280 bytes) 2021-04-27 15:52 https://bugs.astron.com/file_download.php?file_id=223&type=bug

Notes
(0003604) christos    2021-04-27 20:36	applied, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
261	[file] General	minor	always	2021-04-20 11:24	2021-04-27 19:39
Reporter:	bitstreamout	Platform:	x86_64
Assigned To:	christos	OS:	openSUSE
Priority:	normal	OS Version:	Tumbleweed
Status:	resolved	Product Version:	5.40
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.41
		Target Version:
Summary:	New version breaks subversion tests
Description:	Currently subversion build breaks at several points ... many of the breaks are caused by behaviour change of file in detecting ASCII text without newlines.
Tags:
Steps To Reproduce:	With version 4.30 echo xx | file - /dev/stdin: ASCII text, with no line terminators with version 5.40 echo -n xx | file - /dev/stdin: data
Additional Information:
Attached Files:	fails.log (18,188 bytes) 2021-04-22 15:47 https://bugs.astron.com/file_download.php?file_id=221&type=bug file-5.50-ascii.patch (699 bytes) 2021-04-23 07:36 https://bugs.astron.com/file_download.php?file_id=222&type=bug

Notes
(0003593) bitstreamout    2021-04-21 05:58	Just to correct typo ... the 'With version 4.30' should be 'With version 5.39' ``` /suse/werner> file --version file-5.39 magic file from /etc/magic:/usr/share/misc/magic /suse/werner> echo -n xx | file - /dev/stdin: ASCII text, with no line terminators /suse/werner> ```
(0003594) bitstreamout    2021-04-21 08:38	Could it be that the condition if (u < 3) within the LOOKS_ macro should be if (u < 2) at least for ASCII and latin1
(0003595) bitstreamout    2021-04-22 12:56	Duplicate of https://bugs.astron.com/view.php?id=256
(0003596) bitstreamout    2021-04-22 15:25	Hmmm ... still problems with files without last newline ``` abuild@noether:~/rpmbuild/BUILD/subversion-1.14.1> wc -c /dev/shm/svn-test-work/working_copies/merge_tests-2/A/B/F/foo 3 /dev/shm/svn-test-work/working_copies/merge_tests-2/A/B/F/foo abuild@noether:~/rpmbuild/BUILD/subversion-1.14.1> file /dev/shm/svn-test-work/working_copies/merge_tests-2/A/B/F/foo /dev/shm/svn-test-work/working_copies/merge_tests-2/A/B/F/foo: data abuild@noether:~/rpmbuild/BUILD/subversion-1.14.1> cat /dev/shm/svn-test-work/working_copies/merge_tests-2/A/B/F/foo && echo foo ```
(0003597) bitstreamout    2021-04-22 15:27	Test with file 5.39 ``` file /abuild/oscbuild/openSUSE_Tumbleweed/dev/shm/svn-test-work/working_copies/merge_tests-2/A/B/F/foo /abuild/oscbuild/openSUSE_Tumbleweed/dev/shm/svn-test-work/working_copies/merge_tests-2/A/B/F/foo: ASCII text, with no line terminators ```
(0003598) bitstreamout    2021-04-22 15:47	The fails.log of subversion with file 5.40
(0003599) bitstreamout    2021-04-23 06:58	Something goes wrong even with those commits for bug PR/256 ``` abuild@noether:~/rpmbuild/BUILD/file-5.40> echo -e "fo" | $PWD/src/.libs/file -m $PWD/magic/magic - /dev/stdin: ASCII text abuild@noether:~/rpmbuild/BUILD/file-5.40> echo -e "xx" | $PWD/src/.libs/file -m $PWD/magic/magic - /dev/stdin: data abuild@noether:~/rpmbuild/BUILD/file-5.40> echo -e "hi" | $PWD/src/.libs/file -m $PWD/magic/magic - /dev/stdin: ASCII text abuild@noether:~/rpmbuild/BUILD/file-5.40> echo -en "hi" | $PWD/src/.libs/file -m $PWD/magic/magic - /dev/stdin: ASCII text, with no line terminators abuild@noether:~/rpmbuild/BUILD/file-5.40> echo -en "foo" | $PWD/src/.libs/file -m $PWD/magic/magic - /dev/stdin: data abuild@noether:~/rpmbuild/BUILD/file-5.40> echo -e "foo" | $PWD/src/.libs/file -m $PWD/magic/magic - /dev/stdin: ASCII text abuild@noether:~/rpmbuild/BUILD/file-5.40> echo -e "xxx" | $PWD/src/.libs/file -m $PWD/magic/magic - /dev/stdin: data ```
(0003600) bitstreamout    2021-04-23 07:36	I suggest the attached patch to count every ASCII character even if it appears several times
(0003601) bitstreamout    2021-04-23 11:07	I see that commit 3096f87f823e1e936139e48d6a3bae9a95557861 had introduced the `if (dist[i]) u++` which misdetect smaller ASCII files with and without newlines
(0003603) christos    2021-04-27 19:39	The whole character count/distribution approach leads to more confusion as it tries to solve some corner cases. It is not worth using heuristics to resolve the corner cases. I've reverted the fix to PR/180 and that should bring back the original behavior.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
180	[file] General	trivial	always	2020-08-15 05:30	2021-04-27 19:35
Reporter:	EuphCat	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	A file filled with 0xFF gets reported to be ISO-8859
Description:	* I don't know how the parser works, or how file types are managed. I'm okay with NOTABUG A file filled with 0xFF gets reported to be ISO-8859. I find this misleading.
Tags:
Steps To Reproduce:	$ dd if=/dev/zero ibs=1k count=1 | tr "\000" "\377" > 0xFFfile.bin 1+0 records in 2+0 records out 1024 bytes (1.0 kB, 1.0 KiB) copied, 0.000256375 s, 4.0 MB/s $ xxd ./0xFFfile.bin | head 00000000: ffff ffff ffff ffff ffff ffff ffff ffff ................ 00000010: ffff ffff ffff ffff ffff ffff ffff ffff ................ 00000020: ffff ffff ffff ffff ffff ffff ffff ffff ................ 00000030: ffff ffff ffff ffff ffff ffff ffff ffff ................ 00000040: ffff ffff ffff ffff ffff ffff ffff ffff ................ 00000050: ffff ffff ffff ffff ffff ffff ffff ffff ................ 00000060: ffff ffff ffff ffff ffff ffff ffff ffff ................ 00000070: ffff ffff ffff ffff ffff ffff ffff ffff ................ 00000080: ffff ffff ffff ffff ffff ffff ffff ffff ................ 00000090: ffff ffff ffff ffff ffff ffff ffff ffff ................ $ file 0xFFfile.bin 0xFFfile.bin: ISO-8859 text, with very long lines, with no line terminators
Additional Information:	Because of this issue, mkfs.ext4 reports false positive on file validity confirmation. "/dev/sda2 contains `ISO-8859 text, with very long lines, with no line terminators` Proceed anyway? (y,N)"
Attached Files:

Notes
(0003447) christos    2020-08-15 12:06	Fixed by requiring at least 3 distinct character values.
(0003602) christos    2021-04-27 19:35	Reverted the fix. Breaks other tests. A file can have the same character repeated many times and that should not change how file detects it. Heuristics just add confusion to the behavior.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
253	[file] General	minor	always	2021-03-31 11:46	2021-04-19 19:04
Reporter:	rwmjones	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.40
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.41
		Target Version:
Summary:	file 5.40 can no longer print ext4 filesystem UUIDs correctly.
Description:	file 5.40 can no longer print ext4 filesystem UUIDs correctly. Reported in Fedora: file-5.40-1.fc35.x86_64 Downstream bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1945122
Tags:
Steps To Reproduce:	1. Prepare a disk image in a file:   $ rm /var/tmp/test.img   $ truncate -s 1G /var/tmp/test.img   $ mkfs.ext4 /var/tmp/test.img 2. Run 'file' against it to display the UUID. With the previous version of file it would display the UUID correcctly, eg:   $ file /var/tmp/test.img   /var/tmp/test.img: Linux rev 1.0 ext4 filesystem data, UUID=b1bc22cc-7392-4780-8b50-77dac556236d (extents) (64bit) (large files) (huge files) With the current version of file it displays it incorrectly, eg:   $ file /var/tmp/test.img   /var/tmp/test.img: Linux rev 1.0 ext4 filesystem data, UUID=b1bc22cc-7392-4780-ffff8b50-77dac556236d (extents) (64bit) (large files) (huge files) Notice that some parts of the UUID are sign-extended.
Additional Information:	I bisected this to the following upstream commit:   0478d9251abafd0876cdb3121ef2c07af6c99513 is the first bad commit   commit 0478d9251abafd0876cdb3121ef2c07af6c99513   Author: Christos Zoulas <christos@zoulas.com>   Date: Sat Aug 22 18:27:42 2020 +0000     Treat printf numbers as signed.    src/softmagic.c | 28 ++++++++++++++--------------    1 file changed, 14 insertions(+), 14 deletions(-)
Attached Files:

Notes
(0003580) rwmjones    2021-03-31 11:57	The magic entry (magic/Magdir/filesystems) specifies %08x and %04x for the fields of the UUID. Normally %x would be unsigned (eg. the printf(3) man page documents this). So I think this is a regression in "file" itself, not a bug in the magic data.
(0003592) christos    2021-04-19 19:04	Thanks! The type and sign-ness of argument is determined by the magic type field and this has been fixed to be unsigned now.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
256	[file] General	major	always	2021-04-02 18:41	2021-04-19 18:38
Reporter:	mutableVoid	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.40
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.41
		Target Version:
Summary:	Wrong file type for file with one-bit char before new-line
Description:	When I execute `file` on a file that contains only a single (one-byte) character before the newline which terminates the file, the reported file type is binary instead of Unicode text (see section: Steps to reproduce). This messes which programs like `more`, which therefore refuse to print the file's content, as the reported file type is binary. I encountered this in the following scenario: ```bash > printf 'h\n' > file2 > more file2   ******** file2: Not a text file ******** > od -x file2 0000000 0a68 0000002 ``` When I fill the file with a character that takes more than a single byte in Unicode, the problem does not occur: ```bash printf 'ä\n' > new_file file new_file new_file: Unicode text, UTF-8 text ```
Tags:
Steps To Reproduce:	```bash printf 'h\n' > new_file file new_file ``` prints `new_file: data` instead of the expected `new_file: Unicode text, UTF-8 text`
Additional Information:
Attached Files:

Notes
(0003582) mutableVoid    2021-04-02 19:03	Might be related to the fix of bugs.astron.com/view.php?id=180 , printing the same character multiple times also reports `binary` instead of UTF-8 text: printf 'aa\n' > new_file file new_file new_file: data
(0003590) christos    2021-04-19 18:38	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
257	[file] General	major	always	2021-04-03 17:05	2021-04-19 17:02
Reporter:	cuihao	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.40
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.41
		Target Version:
Summary:	file -i doesn't recognize xz files
Description:	file -i doesn't recognize xz files possibly because the stock magic file is broken.
Tags:
Steps To Reproduce:	$ file -i xxx.xz With file 5.39, I got: xxx.xz: application/x-xz; charset=binary With newest file 5.40, I got: xxx.xz: application/octet-stream; charset=binary
Additional Information:	I did git-bisect and found commit 3ebd747d (Add checksum for XZ) introduced the bug. I don't know the format so IDK how to fix it. OS: Arch Linux, latest packages Kernel: 5.11.11-zen1-1-zen
Attached Files:

Notes
(0003583) sgallagh    2021-04-12 14:02	Additional downstream bug in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1947317
(0003589) christos    2021-04-19 17:02	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
259	[file] General	minor	always	2021-04-16 09:43	2021-04-19 16:47
Reporter:	aleksandr.v.novichkov	Platform:
Assigned To:	administrator	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.40
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.41
		Target Version:
Summary:	Glueing mime types into one
Description:	New version of file (5.40) glue mime types for mp3 files.
Tags:
Steps To Reproduce:	1. download attached file 2. run command: ``` file --mime-type attachments_audio.mp3 ```
Additional Information:	Actual type is: ``` audio/mpegapplication/octet-stream ``` Expected type is: ``` audio/mpeg ```
Attached Files:	attachments_audio.mp3 (10,493 bytes) 2021-04-16 09:43 https://bugs.astron.com/file_download.php?file_id=220&type=bug

Notes
(0003586) administrator    2021-04-19 16:47	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
260	[file] General	feature	always	2021-04-16 10:04	2021-04-19 15:57
Reporter:	aleksandr.v.novichkov	Platform:
Assigned To:	administrator	OS:
Priority:	high	OS Version:
Status:	feedback	Product Version:	5.40
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Create tests
Description:	Our project uses a libmagic to content file defining. We often find bugs that have already been fixed. It would be a good idea to create tests. We have tests are written in go language, which we can adapt to your project.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003585) administrator    2021-04-19 15:57	There is a tests subdirectory in the file distribution, and a test framework on https://github.com/file/file-tests. Can you convert your test to use either? I don't think that adding a 3rd framework is a good idea :-)

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
213	[file] General	feature	N/A	2020-11-30 14:52	2021-03-28 19:03
Reporter:	Mikhail.Kovalev	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	reopened
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	Chiasmus encrypted files (.xia)
Description:	Chiasmus (https://www.bsi.bund.de/EN/Topics/OtherTopics/Chiasmus/Chiasmus_node.html) is encryption software used by many public authorities in Germany. It would be great if file library could detect .xia files.
Tags:
Steps To Reproduce:
Additional Information:	Detection should be easy: the first characters in the file are always "XIA". An example file is attached.
Attached Files:	example.xia (338 bytes) 2020-11-30 16:50 https://bugs.astron.com/file_download.php?file_id=190&type=bug

Notes
(0003510) christos    2020-12-17 00:04	Added, thanks!
(0003574) Mikhail.Kovalev    2021-03-25 11:43	I am really sorry, but this turned out to be a duplicate. Detection of Chiasmus files was already implemented in https://github.com/file/file/blob/master/magic/Magdir/bsi So the newly added file https://github.com/file/file/blob/master/magic/Magdir/crypto should be removed. The problem is that it's only the "textual description" which gets set if the file type is detected. But the MIME-type remains "application/octet-stream". Which indeed should be the case according to https://datatypes.net/open-xia-files However, in the past there were some attempts to introduce special MIME types for Chiasmus files, e.g. from https://bugs.freedesktop.org/show_bug.cgi?id=23255: - application/x-chiasmus-key Chiasmus key - application/x-chiasmus-encrypted Chiasmus encrypted data Would it be possible to add such MIME types to the File library?
(0003579) christos    2021-03-28 19:03	removed contents from crypto

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
251	[file] General	trivial	always	2021-03-25 22:47	2021-03-27 20:18
Reporter:	vineetg76	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	elf files for Synopsys ARC are not identified correctly
Description:	There are 3 variants of Synopsys ARC ISA: ARCompact, ARCv2 and ARCv3 and processors based on them However current implementation of file is not identifying them ideally: 1. ARCompact based elf is incorrectly identified as legacy ARC Tangent A5 which don't exist. 2. ARCv2 is not even listed 3. ARCv3 is incorrectly identified as ARCv2.3
Tags:
Steps To Reproduce:
Additional Information:	I'm attaching a patch which addresses the above.
Attached Files:	0001-Fix-names-for-Synopsys-ARC-cores.patch (1,858 bytes) 2021-03-25 22:47 https://bugs.astron.com/file_download.php?file_id=213&type=bug

Notes
(0003578) christos    2021-03-27 20:18	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
235	[file] General	tweak	always	2021-02-08 15:26	2021-03-14 17:13
Reporter:	jschleus	Platform:
Assigned To:	christos	OS:
Priority:	low	OS Version:
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	5.39 reports "Certificate" instead of "ASCII text" for the PHP project NEWS file
Description:	file 5.39 (but not 5.38) reports incorrectly "Certificate" instead of "ASCII text" for the NEWS file of the PHP tarballs (e.g. viewable at https://raw.githubusercontent.com/php/php-src/master/NEWS). Probably that is related to an addition in 5.39 to the file magic/Magdir/der (handling DER encoded files). Unfortunately I'm not able to analyze the reason but just for curiosity I created some one-liner files starting with the first line of the mentioned NEWS file and got the following results
Tags:
Steps To Reproduce:
Additional Information:	Unfortunately I'm not able to analyze the reason but just for curiosity I created some one-liner files starting with the first line of the mentioned NEWS file and got the following results: "Certificate": PHP NEWS PHP xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx NEWS PHP xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx pHP xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx pHp xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx "ASCII text": PHA xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx php xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx PHP xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx PHP xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Unfortunately the text here seems not to use a monospaced font (e.g. the first two example lines have both 79 chars).
Attached Files:	file-5.39_CERTIFICATE_bug.tests.txt (714 bytes) 2021-02-08 15:26 https://bugs.astron.com/file_download.php?file_id=202&type=bug

Notes
(0003560) christos    2021-02-24 22:52	I can't reproduce this with the version from HEAD.
(0003562) jschleus    2021-02-25 10:17	Hmm, I just compiled the GitHub R/O master version and could reproduce the described behavior. Perhaps I have expressed myself somewhat imprecisely, for tests with the attached file you have to put only one of the given lines into a test file. But file 5.38 outputs for the NEWS file of the originally mentioned URL "UTF-8 Unicode text", but for the NEWS file of the last PHP 8.0.2 release (https://raw.githubusercontent.com/php/php-src/PHP-8.0.2/NEWS) the mentioned "ASCII text". But the current file 5.39 and the HEAD version output both "Certificate". By the way my tests are done under Linux openSUSE Leap 15.2.
(0003572) christos    2021-03-14 17:13	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
241	[file] General	minor	unable to reproduce	2021-03-02 05:03	2021-03-14 17:03
Reporter:	thesamesam	Platform:	Linux
Assigned To:	christos	OS:	Gentoo GNU/Linux
Priority:	normal	OS Version:	amd64 (stable)
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	file is killed by seccomp filter when executing futex syscall
Description:	A user reported to us in Gentoo that all file invocations, when built with seccomp, resulted in "bad system call" (i.e. killed by the seccomp filter). They were able to produce strace output showing futex() was the problematic syscall, although it's not clear why futex() is being used here. I've attached their system information and strace output. Currently, src/seccomp.c has: >#ifdef XZLIBSUPPORT > ALLOW_RULE(futex); >#endif So, clearly we expect futex in some cases. In this case, the user had not built file with LZMA support, but when they were asked to enable it, the issue disappeared (as expected). Do you have any suggestions as to why this syscall was being used (and if it is problematic - seems not), or does the filter simply need updating to allow it unconditionally?
Tags:
Steps To Reproduce:	Not been able to reproduce, but often these changes are quite sensitive to glibc version and other factors in the system environment. The user's glibc version appeared to be the main version in deployment in Gentoo and has not been visible on any of my systems. This is the only report I've seen of this issue, although in the past we've occasionally seen this style of problem with other syscalls that was resolved by filter updates upstream in file. I am happy to try pass on questions to the user downstream.
Additional Information:	Downstream report in Gentoo: https://bugs.gentoo.org/771096
Attached Files:	emerge_info.txt (7,876 bytes) 2021-03-02 05:03 https://bugs.astron.com/file_download.php?file_id=205&type=bug strace.txt (15,549 bytes) 2021-03-02 05:03 https://bugs.astron.com/file_download.php?file_id=206&type=bug

Notes
(0003571) christos    2021-03-14 17:03	I enabled futexes unconditionally. They are used for threaded programs and it is possible that newer glibc does some thread initialization unconditionally. It would be interesting to find the stack trace of the futex call though.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
242	[file] General	minor	have not tried	2021-03-02 15:31	2021-03-14 16:57
Reporter:	catull	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	Follow-up to 000226, now the marker is 4 bytes long
Description:	The Birtual Machine file marker was originally introduced as a 2-byte marker. Now the implementor has adopted a larger marker. The diff attached to this ticket accounts for the most recent change.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	bm.diff (676 bytes) 2021-03-02 15:31 https://bugs.astron.com/file_download.php?file_id=207&type=bug

Notes
(0003570) christos    2021-03-14 16:57	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
243	[file] General	minor	have not tried	2021-03-02 15:45	2021-03-14 16:54
Reporter:	catull	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	Add libmagic.pc to .gitignore
Description:	When developing under git, the generated file above appears as "untracked file", see below. With the patch applied, it will be duely ignored by git.
Tags:
Steps To Reproduce:	git clone git@github.com:file/file.git cd file autoreconf -f -i ./configure make git status -b
Additional Information:	The last command shows: ➜ file.git git:(master) git status -b On branch master Your branch is up to date with 'origin/master'. Untracked files:   (use "git add <file>..." to include in what will be committed)     libmagic.pc nothing added to commit but untracked files present (use "git add" to track)
Attached Files:	gitignore.diff (213 bytes) 2021-03-02 15:45 https://bugs.astron.com/file_download.php?file_id=208&type=bug

Notes
(0003569) christos    2021-03-14 16:54	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
244	[file] General	feature	always	2021-03-08 17:23	2021-03-14 16:52
Reporter:	mainframed767	Platform:	64
Assigned To:	christos	OS:	Linux
Priority:	normal	OS Version:	Ubuntu 20.04
Status:	resolved	Product Version:	5.38
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	Detect NETDATA (z/OS and CMS XMI) files
Description:	NETDATA (https://en.wikipedia.org/wiki/NETDATA) is a simple file format used to move files between mainframes, oftentimes referred to as XMI or XMIT. More information and test files here: http://planetmvs.com/unxmit/ NETDATA files are stored in EBCDIC. The first two bytes are a size and a flag, which varies, followed by 'INMR01' in ebcdic followed by IBM text unit INMLRECL whic is always the same: 00000002 c9 d5 d4 d9 f0 f1 00 42 00 01 00 01 50 10 11 00 It would be great if detection for this format could be added. At the moment it is just reported as "data". Attached is a sample: seq.xmi
Tags:
Steps To Reproduce:	1) Generate XMI file using TSO TRANSMIT: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.ikjc500/transmi.htm 2) Transfer file to local machine 3) Run 'file' against the downloaded file
Additional Information:
Attached Files:	seq.xmi (560 bytes) 2021-03-08 17:23 https://bugs.astron.com/file_download.php?file_id=209&type=bug

Notes
(0003568) christos    2021-03-14 16:52	Added a simple detection for now. We can get more elaborate and extract the fields if needed.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
246	[file] General	minor	always	2021-03-13 11:56	2021-03-14 16:37
Reporter:	Kid	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	video/mp4 identified as application/octet-stream
Description:	The only thing possibly unusual I see is ftypiso4 instead of ftypisom. Thank you for maintaining this essential utility. The OS is Arch Linux.
Tags:	magic
Steps To Reproduce:
Additional Information:
Attached Files:	2KiB.mp4 (2,048 bytes) 2021-03-13 11:56 https://bugs.astron.com/file_download.php?file_id=211&type=bug

Notes
(0003567) christos    2021-03-14 16:37	Fixed in HEAD, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
247	[file] General	feature	N/A	2021-03-14 10:18	2021-03-14 16:24
Reporter:	akohlmey	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.38
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	Magic file patterns for the LAMMPS MD code
Description:	The LAMMPS MD simulation code ( https://lammps.sandia.gov/ ) produces several binary and text mode files that can be easily recognized with the additional patterns in the file attached to this issue.
Tags:	magic
Steps To Reproduce:	Example output (tested on a Fedora Linux, and MacOS 11): $ file *.* dihedral-quadratic.restart: LAMMPS binary restart file (rev 2), Version 10 Mar 2021, Little Endian mol-pair-wf_cut.restart: LAMMPS binary restart file (rev 2), Version 24 Dec 2020, Little Endian atom.bin: LAMMPS atom style binary dump (rev 2), Little Endian, First time step: 445570 custom.bin: LAMMPS custom style binary dump (rev 2), Little Endian, First time step: 100 bn1.lammpstrj: LAMMPS text mode dump, First time step: 5000 data.fourmol: LAMMPS data file written by LAMMPS pnc.data: LAMMPS data file written by msi2lmp data.spce: LAMMPS data file written by TopoTools B.data: LAMMPS data file written by OVITO log.lammps: LAMMPS log file written by version 10 Feb 2021
Additional Information:
Attached Files:	magic.lammps (2,329 bytes) 2021-03-14 10:18 https://bugs.astron.com/file_download.php?file_id=212&type=bug

Notes
(0003566) christos    2021-03-14 16:24	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
245	[file] General	minor	have not tried	2021-03-11 16:04	2021-03-14 16:22
Reporter:	pamelawardtx2021	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	problems with javascript
Description:	problems with javascript
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	payforresearchpaperonline_a2.docx.pdf (31,104 bytes) 2021-03-11 16:04 https://bugs.astron.com/file_download.php?file_id=210&type=bug

Notes
(0003565) christos    2021-03-14 16:22	spam

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
214	[tcsh] General	minor	always	2020-12-05 00:40	2021-02-27 01:02
Reporter:	andrew@ugh.net.au	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:	6.22.03
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Can't escape delimiters in :s modifier
Description:	the man page, under "History substitution" for the s modifier says: > Any character may be used as the delimiter in place of `/'; a `\' can be used to quote the delimiter inside l and r. \ does not quote the delimiter currently. I didn't go back to see if it used to work.
Tags:	patch
Steps To Reproduce:	``` >set a='a/b' >echo $a a/b >echo $a:s/\//#/ a/b ``` The output should have been `a#b`
Additional Information:	Patch attached
Attached Files:	sh.dol.c.patch (2,458 bytes) 2020-12-05 00:40 https://bugs.astron.com/file_download.php?file_id=191&type=bug sh.dol.c-2.patch (2,097 bytes) 2020-12-05 00:43 https://bugs.astron.com/file_download.php?file_id=192&type=bug delim.diff (1,412 bytes) 2021-02-27 01:02 https://bugs.astron.com/file_download.php?file_id=204&type=bug

Notes
(0003499) andrew@ugh.net.au    2020-12-05 00:43	This replaces the previous patch which somehow had some misplaced comments in it.
(0003563) christos    2021-02-26 14:33	I am wondering if that ever worked and we broke it, or if it never worked and this patch is needed. I need to take a more careful look.
(0003564) christos    2021-02-27 01:02	I think we need to parse both at the lexical level and at dollar evaluation like below.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
237	[file] General	feature	always	2021-02-11 09:17	2021-02-24 23:56
Reporter:	pxeger	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	Detect Ansible Vault files
Description:	Ansible Vault (https://docs.ansible.com/ansible/latest/user_guide/vault.html) is a simple AES-based file encryption system for Ansible. The exact file format is documented at https://docs.ansible.com/ansible/latest/user_guide/vault.html#format-of-files-encrypted-with-ansible-vault, but essentially the magic bytes are (hexdump): 00000000: 2441 4e53 4942 4c45 5f56 4155 4c54 3b $ANSIBLE_VAULT; It would be great if detection for this format could be added. At the moment it is just reported as "ASCII text". Attached is an example file which contains the content "this is an example file" with the password "123"
Tags:	magic
Steps To Reproduce:	1. Create a file using `ansible-vault create myfile` 2. Enter some content in your editor and save the file 3. Use `file myfile`
Additional Information:
Attached Files:	example_file (419 bytes) 2021-02-11 09:17 https://bugs.astron.com/file_download.php?file_id=203&type=bug

Notes
(0003561) christos    2021-02-24 23:56	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
238	[file] General	text	N/A	2021-02-15 18:16	2021-02-24 22:35
Reporter:	lu3	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	MP4 Base Media v1 has the typo "IS0" (0 as the number zero) instead of "ISO" (O as the letter)
Description:	--- /etc/share/misc/magic/animation.orig 2021-01-19 12:12:37.274757489 +0100 +++ /etc/share/misc/magic/animation 2021-02-15 19:05:48.250105805 +0100 @@ -112,7 +112,7 @@  # ?/enc-isoff-generic  >8 string iso2 \b, MP4 Base Media v2 [ISO 14496-12:2005]  !:mime video/mp4 ->8 string isom \b, MP4 Base Media v1 [IS0 14496-12:2003] +>8 string isom \b, MP4 Base Media v1 [ISO 14496-12:2003]  !:mime video/mp4  >8 string/W jp2 \b, JPEG 2000  !:mime image/jp2
Tags:	magic
Steps To Reproduce:	# file -b movie1.mp4 ISO Media, MP4 v2 [ISO 14496-14] # file -b movie2.mp4 ISO Media, MP4 Base Media v1 [IS0 14496-12:2003]
Additional Information:	For completeness: this is the standard installation on Gentoo Linux, version sys-apps/file-5.39-r3, found in /etc/share/misc/magic/animation.
Attached Files:

Notes
(0003559) christos    2021-02-24 22:35	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
240	[file] General	minor	always	2021-02-19 02:42	2021-02-23 05:27
Reporter:	aodaki	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:	5.39
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	PE files are reported as "for MS Windows" even though they are not
Description:	Today PE files are not just for MS Windows. Especially .NET assemblies and UEFI programs are so common and it is not correct to assume PE files are for MS Windows. I suggest to remove "for MS Windows" from PE file reports, but I would like to hear other opinions if any.
Tags:	magic
Steps To Reproduce:	Download a NuGet package (for example: https://www.nuget.org/packages/Newtonsoft.Json/13.0.1-beta1), extract it, and feed DLLs contained in them.
Additional Information:
Attached Files:

Notes
(0003557) christos    2021-02-23 01:14	This needs windows to extract... Can you paste the first few K of a dll or supply a patch? Thanks!
(0003558) aodaki    2021-02-23 05:27	NuGet tools which can extract the file run anywhere Mono or .NET Core runs, so you don't need Windows and that is the point of this ticket. However, it may be still troublesome to set up a .NET environment if you do not have one now. Fortunately, the file is just a ZIP file as described here: https://docs.microsoft.com/en-us/nuget/what-is-nuget You may just use a ZIP extractor and find files whose name end with .dll.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
236	[file] General	trivial	have not tried	2021-02-08 15:48	2021-02-23 00:52
Reporter:	jschleus	Platform:
Assigned To:	christos	OS:
Priority:	low	OS Version:
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	Codespell report for "file" (on fossies.org)
Description:	I am the administrator of the FOSS server fossies.org that supports (and uses !) also the "file" project and offers among others a feature named "Source code misspelling reports":  https://fossies.org/features.html#codespell Such reports are normally only generated on request, but as Fossies administrator I have just created (animated by another "file" issue I have just opened) such an analysis also for the "file" project:  https://fossies.org/linux/misc/file/codespell.html That version-independent (not linked) URL should redirect always to the last report (if available), so currently to  https://fossies.org/linux/misc/file-5.39.tar.gz/codespell.html Although after a first review obviously wrong matches ("false positives") are already filtered out (ignored) please inform me if you find more of them so that I can force a new improved check if applicable. Although the correction of misspellings and typos has probably not a top priority, I hope that the report can nevertheless be a little bit useful.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003555) christos    2021-02-23 00:52	Ran the following on all the files, thanks! #!/bin/sh sed -E -i \ -e 's/\<intput\>/input/g' \ -e 's/\<enought\>/enough/g' \ -e 's/\<reachs\>/reaches/g' \ -e 's/\<whitch\>/which/g' \ -e 's/\<serie\>/series/g' \ -e 's/\<Unparseable\>/Unparsable/g' \ -e 's/\<colums\>/columns/g' \ -e 's/\<extenstions\>/extensions/g' \ -e 's/\<carrige\>/carriage/g' \ -e 's/\<irregardless\>/regardless/g' \ -e 's/\<resonable\>/reasonable/g' \ -e 's/\<conectix\>/connectix/g' \ -e 's/\<conectix\>/connectix/g' \ -e 's/\<conectix\>/connectix/g' \ -e 's/\<splitted\>/split/g' \ -e 's/\<splitted\>/split/g' \ -e 's/\<positiv\>/positive/g' \ -e 's/\<positiv\>/positive/g' \ -e 's/\<KENREl\>/kernel/g' \ -e 's/\<splitted\>/split/g' \ -e 's/\<splitted\>/split/g' \ -e 's/\<unusal\>/unusual/g' \ -e 's/\<Inforation\>/Information/g' \ -e 's/\<fomrat\>/format/g' \ -e 's/\<libray\>/library/g' \ -e 's/\<annoted\>/annotated/g' \ -e 's/\<positiv\>/positive/g' \ -e 's/\<coresponding\>/corresponding/g' \ -e 's/\<informations\>/information/g' \ -e 's/\<assember\>/assembler/g' \ -e 's/\<assember\>/assembler/g' \ -e 's/\<informations\>/information/g' \ -e 's/\<informations\>/information/g' \ -e 's/\<signatur\>/signature/g' \ -e 's/\<environent\>/environment/g' \ -e 's/\<temporily\>/temporarily/g' \ -e 's/\<gziped\>/gzipped/g' \ -e 's/\<Versio\>/Version/g' \ -e 's/\<revsion\>/revision/g' \ -e 's/\<positiv\>/positive/g' \ -e 's/\<positiv\>/positive/g' \ -e 's/\<partiton\>/partition/g' \ -e 's/\<formated\>/formatted/g' \ -e 's/\<formated\>/formatted/g' \ -e 's/\<formated\>/formatted/g' \ -e 's/\<posible\>/possible/g' \ -e 's/\<splitted\>/split/g' \ -e 's/\<possibilites\>/possibilities/g' \ -e 's/\<instread\>/instead/g' \ -e 's/\<programm\>/program/g' \ -e 's/\<extraced\>/extracted/g' \ -e 's/\<unusal\>/unusual/g' \ -e 's/\<positiv\>/positive/g' \ -e 's/\<3nd\>/3rd/g' \ -e 's/\<charcter\>/character/g' \ -e 's/\<nane\>/name/g' \ -e 's/\<3nd\>/3rd/g' \ -e 's/\<CYMK\>/CMYK/g' \ -e 's/\<explict\>/explicit/g' \ "$@"

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
229	[file] General	block	always	2021-01-15 13:58	2021-02-09 11:26
Reporter:	JoergS	Platform:	VirtualBox image
Assigned To:	christos	OS:	Ubuntu (Linux)
Priority:	normal	OS Version:	16.04
Status:	assigned	Product Version:	5.39
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	fit-map-data.testfile does not match fit-map-data.result, thus file-5.39 compilation (Yocto 3.2.1) always fails!
Description:	when building "file-5.39" in a Yocto-3.2.1 environment, its recipe always fails with the following error (excerpt): | Running test: ../../git/tests/fit-map-data.testfile | Error: result was | FIT Map data, unit id 65536, serial 3879446968, Sat May 31 12:00:34 2014, manufacturer 1 (garmin), product 1632, type 4 (Activity) | expected: | FIT Map data, unit id 65536, serial 3879446968, Sat May 31 10:00:34 2014, manufacturer 1 (garmin), product 1632, type 4 (Activity) | ../../git/tests/fit-map-data.testfile: FIT Map data, unit id 65536, serial 3879446968, Sat May 31 12:00:34 2014, manufacturer 1 (garmin), product 1632, type 4 (Activity) I have tested "file" with the provided fit testdata (git/tests/fit-map-data.testfile) with two other versions of "file" (5.25 and 5.32) and both give the same result as in the Yocto build! (i.e. NOT the expected result: the timestamp differs for 2 hours!) please fix the expected result for the fit test.
Tags:
Steps To Reproduce:	just execute: (in the file repo) file tests/fit-map-data.testfile this will produce: fit-map-data.testfile: FIT Map data, unit id 65536, serial 3879446968, Sat May 31 12:00:34 2014, manufacturer 1 (garmin), product 1632, type 4 (Activity) while the expected result for the automated test expects the timestamp to be "Sat May 31 10:00:34 2014" - 2 hours earlier
Additional Information:	I don't know-if(/think-that) this is related to the virtual box I am running Ubuntu-16.04 in, I have no other machine to test that; but the current time (output of the "time" command) is correct...
Attached Files:

Notes
(0003528) JoergS    2021-01-15 14:10	the used commit for the file repo is: 87731415de945660b00f02207d8e9d986ef9b82e (poky/meta/recipes-devtools/file/file_5.39.bb)
(0003529) polluks    2021-01-22 14:42	Exactly two hours? Smells like GMT vs local time conflict...
(0003530) JoergS    2021-01-25 07:43	Yeah - some timezone problem in our virtual-machine setup or alike - I meanwhile had the chance to run the "file" testsuite on a native Linux server, and there it worked! BUT: why is the timezone even considered? shouldn't "file" simply read the absolute timestamp stored in that test-file and just display it? I mean, if the local timezone is taken into consideration, wouldn't that require many "expected result" files then? one for every existing timezone in the world...
(0003537) christos    2021-02-05 22:03	The formats use FILE_T_LOCAL so they use localtime instead of gmtime. Perhaps they should not?
(0003538) christos    2021-02-05 22:04	It is a timezone issue. Changing FILE_T_LOCAL to 0 in softmagic.c should fix it, but is this better (to print times in GMT by default)?
(0003551) JoergS    2021-02-07 08:40	Well, that file was generated at the displayed time, but in the timezone of the creator of the file, correct? So when I look at the output, without any timezone information, it looks as if it was created in my local timezone... Maybe show the timestamp converted to the local timezone - but in that case, testing would be horrible; probably the better aproach: also show the timezone of the creator (if that info is available) or the timestamp relative to GMT as you suggested!
(0003552) christos    2021-02-08 14:52	It appears that the magic for the maps is written on purpose to use leldate (local) instead of ledate (UTC). I think the easiest way is to stick a TZ=UTC before running the tests.
(0003553) JoergS    2021-02-09 11:26	export TZ=UTC before running the test works for me, thank you very much!!! I think you can close this ticket now, and sorry for even raising this - wasn't a "file" problem at all in the end...

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
205	[file] General	feature	N/A	2020-10-23 12:27	2021-02-06 21:45
Reporter:	utoddl	Platform:
Assigned To:	christos	OS:
Priority:	low	OS Version:
Status:	assigned	Product Version:	5.38
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	option to indicate whether txt files have terminating line ending
Description:	It would be nice to have an option to indicate whether the last line of a text file, or really any file that's made of lines of text, has a terminator on it's last line. This could be off by default since it would involve a seek to the end and thus could impact performance and backward compatibility in the output. Or not, if that's not a big deal.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003545) christos    2021-02-05 23:03	That's not easy because we don't always read the whole file.
(0003548) utoddl    2021-02-05 23:27	Exactly why I suggested it would have to be an off-by-default option. (Although now I'm having second thoughts...) It would only apply to inputs which had already been determined to be some sort of "text" in a seekable file, and not from some exotic source like a pipe. Only then would it be reasonable to seek to the end (certainly not reading all the data -- that could be huge) and check the last couple of bytes for some combination of CR and LF, at which point an appropriate string could be added to that file's output.
(0003549) christos    2021-02-06 13:08	All this is doable, but the cost-benefit (from both the code complexity and performance perspective) leans heavily on the cost and not the benefit..
(0003550) utoddl    2021-02-06 21:45	I just crawled around through the code, and, yeah, I have to agree with you. :( It seems such a simple ask, but the existing code would have to be significantly reworked to wedge it in. I'm sorry to say we can let this one go until the next extreme makeover, because that's what it would take. If you ever get the ./TODO list knocked out, particularly such that struct buffer becomes a thing that you can query, reload different parts of, etc., then implementing tests at the tail end of files would be much more straightforward. You'd still have to deal with piped data which may be very large or even unending. It would be neat if it could say for example how many pages are in a .pdf or how many YAML bodies are in a .yaml or whether a text file is terminated. It would also be neat if `file` could produce its output in a format more consumable by scripts, maybe json. But that a different RFQ altogether. Thanks anway.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
231	[file] General	minor	always	2021-01-24 01:23	2021-02-05 23:21
Reporter:	jidanni	Platform:
Assigned To:	christos	OS:
Priority:	low	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Empty file, or Empty directory?
Description:	$ touch AA $ file AA AA: empty # Empty file, or Empty directory? $ mkdir BB $ file BB BB: directory # Well, you told us if a file is empty or not, you should also on directories too.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003539) christos    2021-02-05 22:07	It is doable, but then you need to deal with errors (what if permission denied etc.). More trouble than worth.
(0003547) jidanni    2021-02-05 23:21	OK. Too bad.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
224	[file] General	minor	have not tried	2021-01-04 12:59	2021-02-05 23:04
Reporter:	jidanni	Platform:
Assigned To:	christos	OS:
Priority:	none	OS Version:
Status:	feedback	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Move to GitHub
Description:	Gosh, this Mantis stuff is unfamiliar. Everybody is moving to GitHub. Perhaps get on the bandwagon. (Yes, a terrible bug report.)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003546) christos    2021-02-05 23:04	Yes, it is in the plans, but no time yet.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
223	[file] General	trivial	have not tried	2021-01-04 12:56	2021-02-05 23:02
Reporter:	jidanni	Platform:
Assigned To:	christos	OS:
Priority:	low	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	there should be an option to tell the user just how long long lines are
Description:	$ file www.youtube.com.har www.youtube.com.har: UTF-8 Unicode text, with very long lines OK, but there should be an option to tell the user just how long. 1234 chars?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003544) christos    2021-02-05 23:02	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
228	[file] General	minor	always	2021-01-13 19:04	2021-02-05 22:56
Reporter:	ahupp	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	5.39 reports incorrect mime type for zip v2.0 files
Description:	file 5.39 reports the mime type of a zip v2.0 file as "applicaction/octet-stream", while 5.38 correctly reports application/zip. This was reproduced on archlinux. Full details to reproduce the problem (creating the zip file, specific versions of arch) can be found here: https://github.com/destream-py/destream/pull/20
Tags:
Steps To Reproduce:	See https://github.com/destream-py/destream/pull/20#issuecomment-759650829, and the instructions above that comment to create the zip file.
Additional Information:
Attached Files:

Notes
(0003543) christos    2021-02-05 22:56	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
230	[file] General	minor	sometimes	2021-01-22 14:30	2021-02-05 22:29
Reporter:	polluks	Platform:	PowerBook5,8
Assigned To:	christos	OS:	MorphOS
Priority:	normal	OS Version:	3.15
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	INI: extra CR
Description:	extra CR of a DOS INI file is not suppressed
Tags:
Steps To Reproduce:	> file dict.ini dict.ini: Generic INItialization configuration [LocaleInfo]\015
Additional Information:
System Description
Attached Files:	dict.ini (79 bytes) 2021-01-22 14:30 https://bugs.astron.com/file_download.php?file_id=200&type=bug

Notes
(0003541) christos    2021-02-05 22:17	Can you change the magic from "regex" to "regex/T" and see if that works?
(0003542) christos    2021-02-05 22:29	Since you supplied an example, you also get a fix :-)

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
227	[file] General	text	always	2021-01-13 16:08	2021-02-05 22:08
Reporter:	mb720	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	Missing word in man page
Description:	In the "Description" part of the man page it reads: >The concept of a “magic” has been applied by extension to data files. I think it should read: >The concept of a “magic number” has been applied by extension to data files.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	file.man.patch (534 bytes) 2021-01-13 17:25 https://bugs.astron.com/file_download.php?file_id=199&type=bug

Notes
(0003525) catull    2021-01-13 17:14	Rather than "magic number", I would use "magic marker" here. There are not always numbers, but alpha-numeric instances.
(0003526) catull    2021-01-13 17:25	Here's a simple patch
(0003527) polluks    2021-01-14 12:52	Well, magic number is a technical term https://en.wikipedia.org/wiki/Magic_number_(programming) At machine level everything is a number ;-)
(0003540) christos    2021-02-05 22:08	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
232	[file] General	minor	always	2021-01-27 23:38	2021-02-05 21:58
Reporter:	ratschance	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	Devicetrees with a structure section larger than 1MB are not correctly identified
Description:	The current implementation for the detection of Linux devicetree files does two checks to see whether the structure and strings sections are within the device tree blob. It seems like `file` only reads 1MB of the devicetree into its in memory buf, and so when the structure section is larger than 1MB, the check for the strings section becomes an out of bounds index into that buf and results in the devicetree not being identified. I have attached a patch of a potential fix.
Tags:	magic
Steps To Reproduce:	This becomes easy to reproduce when using U-Boot's Flattened Image Tree (FIT) format, which uses the device tree compiler to build a device tree blob containing boot images (kernel, rootfs, DTBs) and configurations. More info: https://gitlab.denx.de/u-boot/u-boot/-/blob/master/doc/uImage.FIT/source_file_format.txt The following uses the `mkimage` command from the u-boot-tools package on Ubuntu: # dd if=/dev/zero of=test-900K.bin bs=900K count=1 # mkimage -f auto -A arm -O linux -T ramdisk -C none -e 0 -d test-900K.bin 900k.itb # file 900k.itb 900k.itb: Device Tree Blob version 17, size=923172, boot CPU=0, string block size=102, DT structure block size=922016 # dd if=/dev/zero of=test-1M.bin bs=1M count=1 # mkimage -f auto -A arm -O linux -T ramdisk -C none -e 0 -d test-1M.bin 1m.itb # file 1m.itb 1m.itb: data Expected output: 1m.itb: Device Tree Blob version 17, size=1050148, boot CPU=0, string block size=102, DT structure block size=1048992
Additional Information:
Attached Files:	devicetree_1m_support.patch (1,054 bytes) 2021-01-27 23:38 https://bugs.astron.com/file_download.php?file_id=201&type=bug

Notes
(0003536) christos    2021-02-05 21:58	Applied, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
226	[file] General	feature	have not tried	2021-01-08 17:59	2021-02-05 21:55
Reporter:	catull	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	Add support for "Birtual Machine" (not a typo)
Description:	There is a stack-based VM called "Birtual Machine" being developed. It comes with its own assembly language (BASM) and compiled image. The image file has a header with magic marker 'bm', a version number and some size numbers. This issue implements the magdir entries for reporting the meta information of Birtual Machine images. More details are available here: https://github.com/tsoding/bm.
Tags:	magic, patch
Steps To Reproduce:
Additional Information:
Attached Files:	bm.patch (1,127 bytes) 2021-01-08 17:59 https://bugs.astron.com/file_download.php?file_id=198&type=bug

Notes
(0003535) christos    2021-02-05 21:55	I added it, but the magic is really weak. It is 2021 and we are making 2 byte magic entries? Please let the developers know that they should have at least a 4 byte magic. If there are conflicts/complaints in the future it will be removed.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
233	[file] General	trivial	always	2021-01-31 01:31	2021-02-05 21:51
Reporter:	endrift	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	magic/console: Game Boy ROM Image RAM size is wrong for byte 03
Description:	For Game Boy ROM images where the RAM size byte is 03, libmagic/file says the RAM is 128 Kbits, but it is in fact 256 Kbits, as documented here: https://gbdev.io/pandocs/#_0149-ram-size and plenty of other places, including just looking at photos of cartridges like Link's Awakening DX (https://gbhwdb.gekkio.fi/static/DMG-AZLP-0/gekkio-1_02_pcb_front.jpg) which explicitly says the RAM chip is 256 Kbits on the PCB and chip. Seems like a pretty trivial fix.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003534) christos    2021-02-05 21:51	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
234	[file] General	major	have not tried	2021-02-03 12:13	2021-02-05 21:34
Reporter:	halaei	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.38
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	Memory problems running finfo::buffer with PHP_CLI
Description:	PHP internally uses libmagic for getting information about files. This sample php code consumes 483 MB of RAM for detecting mimetype of a 48 MB MP3 file using php7.4 but it uses only 56 MB with php7.2.     $finfo = new finfo(FILEINFO_MIME_TYPE, '');     $contents = file_get_contents('file.mp3');     echo($finfo->buffer($contents)); The bug is reported to php as well. They say it should be reported to libmagic. See https://bugs.php.net/bug.php?id=79263 The PHP bug is over 1 year old. I reported the bug here as well: https://bugs.launchpad.net/ubuntu/+bug/1914401 .Maybe it wasn't the right place
Tags:
Steps To Reproduce:	Having a large file.mp3 file. Run the following using php 7.4: <?php     $finfo = new finfo(FILEINFO_MIME_TYPE, '');     $contents = file_get_contents('file.mp3');     echo($finfo->buffer($contents));     echo(memory_get_peak_usage(true)/1024/1024);
Additional Information:
Attached Files:

Notes
(0003533) christos    2021-02-05 21:34	file_buffer(3) passed the full size of the buffer to the encoding determination function. If the file was too large, we ended up allocating (2 * size + 4 * size) buffers to scan for encoding. Now we limit size to 64K.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
77	[file] General	minor	always	2019-04-29 13:35	2021-02-01 17:33
Reporter:	yarikoptic	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	feedback	Product Version:	5.35
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	-k, --keep-going does not list other hits - the other one might come out empty
Description:	Detected while trying to workaround recently added detection of .json as application/json and not as text/plain. I thought that I would obtain both new application/json and text/plain if I use --keep-going . But the 2nd entry comes out to be blank. As you can see below it is not happening for some other files, and is not unique to json
Tags:
Steps To Reproduce:	/tmp > file --version file-5.35 magic file from /etc/magic:/usr/share/misc/magic /tmp > echo '{"a": 1}' >| file.json /tmp > file --mime-type file.json file.json: application/json /tmp > file --mime-type -k file.json file.json: application/json\012- \012- /tmp > file --mime-type -k /usr/bin/* | head /usr/bin/[: application/x-pie-executable\012- application/octet-stream /usr/bin/0alias: application/x-pie-executable\012- application/octet-stream /usr/bin/0desktop: application/x-pie-executable\012- application/octet-stream /usr/bin/0install: application/x-pie-executable\012- application/octet-stream /usr/bin/0launch: application/x-pie-executable\012- application/octet-stream /usr/bin/0store: application/x-pie-executable\012- application/octet-stream /usr/bin/0store-secure-add: application/x-pie-executable\012- application/octet-stream /usr/bin/2to3: text/x-python\012- /usr/bin/2to3-2.7: text/x-python\012- /usr/bin/2to3-3.4: text/x-python\012- /tmp > file --mime-type -k /usr/bin/* > /tmp/usr-bin-mime-types /tmp > grep '\012- .*\012' /tmp/usr-bin-mime-types | head /usr/bin/ack: text/x-perl\012- text/x-c\012- /usr/bin/aclocal-1.16: text/x-perl\012- \012- /usr/bin/afmtodit: text/x-perl\012- \012- /usr/bin/apt-file: text/x-perl\012- \012- /usr/bin/apt-rdepends: text/x-perl\012- \012- /usr/bin/apxs: text/x-perl\012- \012- /usr/bin/aspell-import: text/x-perl\012- \012- /usr/bin/autoheader: text/x-perl\012- \012- /usr/bin/autom4te: text/x-perl\012- \012- /usr/bin/automake-1.16: text/x-perl\012- \012-
Additional Information:
Attached Files:

Notes
(0003243) christos    2019-05-06 21:24	Fixed on HEAD.
(0003531) sr-verde    2021-02-01 08:50	Can confirm that issue for version 5.39. Any progress here? $ file -v file-5.39 magic file from /usr/share/file/misc/magic seccomp support included $ file -k --mime-type /tmp/some.json /tmp/some.json: application/json\012- $ file -k --mime-type /tmp/some.csv /tmp/some.csv: application/csv\012-
(0003532) christos    2021-02-01 17:33	I committed a change to HEAD. Please try again.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
222	[file] General	minor	have not tried	2021-01-04 09:57	2021-01-04 19:48
Reporter:	ryoon	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	Add more Citrus locale database file support
Description:	Citrus LC_CTYPE is detected currently, however the other types are not detected. Add more types. See: LC_MONETARY: Citrus locale declaration for LC_MONETARY LC_NUMERIC: Citrus locale declaration for LC_NUMERIC LC_TIME: Citrus locale declaration for LC_TIME SYS_LC_MESSAGES: Citrus locale declaration for LC_MESSAGES
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	file-more-citrus-db-files.diff (459 bytes) 2021-01-04 09:57 https://bugs.astron.com/file_download.php?file_id=197&type=bug

Notes
(0003523) christos    2021-01-04 19:48	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
225	[file] General	major	N/A	2021-01-04 14:14	2021-01-04 19:45
Reporter:	brian	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.38
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	Any way to set parameters with python bindings?
Description:	I can't see any way to do the equivalent of: file -Pelf_phnum=10000 core with the python bindings. Am I just not seeing it?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003522) christos    2021-01-04 19:45	Added getparam/setparam in HEAD.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
221	[file] General	minor	have not tried	2020-12-31 08:25	2021-01-03 21:01
Reporter:	ryoon	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	Add font name for PostScript Printer Font Binary
Description:	Please add font name for .pfb file. For example: 0510A___.PFB: PostScript Type 1 font program data (AmeliaBT-Regular 003.001)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	pfb-font-name.diff (510 bytes) 2020-12-31 08:25 https://bugs.astron.com/file_download.php?file_id=196&type=bug

Notes
(0003521) christos    2021-01-03 21:01	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
220	[file] General	minor	have not tried	2020-12-31 08:19	2021-01-03 20:59
Reporter:	ryoon	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	Add compression method for ZIP archive file
Description:	Please include compression method to the output for ZIP archives. For example: deflate.zip: Zip archive data, at least v2.0 to extract, compression method=deflate bzip2.zip: Zip archive data, at least v4.6 to extract, compression method=bzip2 lzma.zip: Zip archive data, at least v6.3 to extract, compression method=lzma aes-256.zip: Zip archive data, at least v5.1 to extract, compression method=AES Encrypted
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	zip-comp-method.diff (400 bytes) 2020-12-31 08:19 https://bugs.astron.com/file_download.php?file_id=195&type=bug

Notes
(0003520) christos    2021-01-03 20:59	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
219	[file] General	feature	N/A	2020-12-28 17:24	2021-01-03 20:56
Reporter:	jtn	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	Add support for identifying LocoScript documents
Description:	The attached patch adds magic for documents created by LocoScript, a word-processor from the 1980s/1990s. More information about LocoScript: http://fileformats.archiveteam.org/wiki/LocoScript
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	0001-Add-magic-for-LocoScript-documents.patch (1,030 bytes) 2020-12-28 17:24 https://bugs.astron.com/file_download.php?file_id=194&type=bug

Notes
(0003519) christos    2021-01-03 20:56	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
218	[file] General	feature	always	2020-12-23 22:19	2021-01-03 20:54
Reporter:	dgilman	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	Add support for e2fsck undo files
Description:	e2fsck supports writing an undo file. Attached is a patch that adds support to libmagic for these files.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	0001-Add-support-for-e2fsck-undo-files.patch (871 bytes) 2020-12-23 22:19 https://bugs.astron.com/file_download.php?file_id=193&type=bug

Notes
(0003518) christos    2021-01-03 20:54	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
208	[file] General	feature	N/A	2020-11-08 20:26	2020-12-21 15:21
Reporter:	polluks	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Support for RISC OS filetypes
Description:	Like "--apple", see https://en.wikipedia.org/wiki/List_of_RISC_OS_filetypes
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003504) christos    2020-12-16 23:35	I am not sure if this is such a good idea. It will make the magic structure grow and I am not sure that many people will use it. Someone will also need to populate the magic entries...
(0003515) polluks    2020-12-21 14:19	I know what you mean... https://riscosopen.org/forum/forums/5/topics/3933 However every Raspberry Pi user is potentially waiting for `--riscos` and there should be not much overhead. Someone = myself? ;-)
(0003516) christos    2020-12-21 15:21	It is not that hard to add it... But isn't RiskOS dead?

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
216	[file] General	feature	N/A	2020-12-20 00:12	2020-12-20 16:18
Reporter:	polluks	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	CBM BASIC support
Description:	--- c64.bak 2020-10-08 01:28:46 +0200 +++ c64 2020-12-20 00:58:42 +0100 @@ -58,3 +58,9 @@    # bm bitmap  0 string BM\xCB\x02 VDC bitmap + +# CBM BASIC (cc65 compiled) +0 leshort 0x0801 +>2 leshort 0x080b +>6 string \x9e CBM BASIC +>7 string >\0 \b, SYS %s
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003514) christos    2020-12-20 16:18	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
211	[file] General	minor	always	2020-11-17 08:13	2020-12-17 20:45
Reporter:	Albrecht	Platform:	Linux
Assigned To:	christos	OS:	Debian
Priority:	normal	OS Version:	Bullseye
Status:	resolved	Product Version:	5.38
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	running file terminates with “ERROR: error reading”
Description:	Running file on the attached sample file terminates with albrecht@deneb:/tmp$ file file-error-sample ; echo $? file-error-sample: ERROR: error reading (Invalid argument) 1 Guessing the MIME type is successful, though: albrecht@deneb:/tmp$ file --mime-type file-error-sample ; echo $? file-error-sample: application/x-executable 0
Tags:
Steps To Reproduce:	1. extract the attached archive 2. run commands as above
Additional Information:
Attached Files:	file-error-sample.zip (1,415 bytes) 2020-11-17 08:13 https://bugs.astron.com/file_download.php?file_id=187&type=bug

Notes
(0003507) christos    2020-12-16 23:50	I can't reproduce it: [6:46pm] 109>./file -m ../magic/magic.mgc error_sample.zip error_sample.zip: Zip archive data, at least v2.0 to extract [6:46pm] 110>./file -v file-5.39 magic file from /usr/local/share/misc/magic [6:49pm] 115>/usr/bin/file -v file-5.38 magic file from /etc/magic:/usr/share/misc/magic [6:49pm] 116>/usr/bin/file error_sample.zip error_sample.zip: Zip archive data, at least v2.0 to extract [6:49pm] 117>uname -a Linux uranus 5.4.0-56-generic 0000062-Ubuntu SMP Mon Nov 23 19:20:19 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
(0003512) Albrecht    2020-12-17 08:01	Umm, sorry, please do not use the ZIP itself, but its extracted contents – I didn't want to post an executable as plain file. I.e. something like: albrecht@deneb:/tmp$ unzip file-error-sample.zip Archive: file-error-sample.zip   inflating: file-error-sample albrecht@deneb:/tmp$ file file-error-sample file-error-sample: ERROR: error reading (Invalid argument)
(0003513) christos    2020-12-17 20:45	Fixed in HEAD: ./file -m ../magic/magic.mgc file-error-sample file-error-sample: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), can't read section at -1, missing section headers at 7136

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
215	[file] General	minor	always	2020-12-16 06:19	2020-12-17 00:11
Reporter:	davide	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	identify NeXT filesystems
Description:	NeXT systems use a dedicated filesystem format based on UFS, it'd be useful for file to identify it properly. There's a straightforward magic string right at the beginning: "NeXT" for v1, "dlV2" for v2 and "dlV3" for v3. The format is documented in a few places: http://homepages.cs.ncl.ac.uk/nick.cook/csc2025/minix/3.2.1/usr/src/sys/sys/bootblock.h (search for "next68k") https://opensource.apple.com/source/IOStorageFamily/IOStorageFamily-44.3/IONeXTPartitionScheme.h (search for "dl_version")
Tags:	file system, magic
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003511) christos    2020-12-17 00:11	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
212	[file] General	feature	always	2020-11-25 02:59	2020-12-16 23:57
Reporter:	adalava	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	Add PowerPC/OpenPOWER ABI descriptions
Description:	I would like to share/upstream this patch I contributed to FreeBSD project to make "file" print description of witch ABI a binary is using. Here's the link with the patch: https://github.com/freebsd/freebsd/commit/313a7febbb346c95212db22a930e16b6c8552ce1#diff-56081bbe590d5b9526e1bdb87ba72927069ffde7ec9742e6e519a3ca5e8ddd7a
Tags:
Steps To Reproduce:
Additional Information:	Output examples: $ file teste-elfv1 teste-elfv1: ELF 64-bit MSB relocatable, 64-bit PowerPC or cisco 7500, Unspecified or Power ELF V1 ABI, version 1 (FreeBSD), not stripped $ file teste-elfv2 teste-elfv2: ELF 64-bit MSB relocatable, 64-bit PowerPC or cisco 7500, OpenPOWER ELF V2 ABI, version 1 (FreeBSD), not stripped
Attached Files:

Notes
(0003509) christos    2020-12-16 23:57	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
207	[file] General	feature	have not tried	2020-10-31 15:44	2020-12-16 23:54
Reporter:	rurban	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	More AutoCAD DWG/DXF
Description:	See the patch. dwg 2020+2021 dxf 2013-2021
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	0001-Add-more-AutoCAD.patch (1,454 bytes) 2020-10-31 15:44 https://bugs.astron.com/file_download.php?file_id=185&type=bug 0001-Add-more-AutoCAD-2.patch (1,876 bytes) 2020-11-24 18:55 https://bugs.astron.com/file_download.php?file_id=188&type=bug

Notes
(0003498) rurban    2020-11-24 18:55	Revised patch which also includes r13c3 detection. These files are unfortunately also in the wild. Replaces the original 0001-Add-more-AutoCAD.patch
(0003508) christos    2020-12-16 23:54	Applied, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
210	[file] General	trivial	always	2020-11-16 12:27	2020-12-16 23:42
Reporter:	Helflym	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	Wrong define for strndup workaround on AIX
Description:	Hi, In softmagic.c (https://github.com/file/file/blob/master/src/softmagic.c#L501), there is a workaround in order to provide strndup if it doesn't exist on the target or on AIX as strndup isn't working as expected. However, the define used for AIX "__aiws__" is unknown to me. It should be "_AIX". Does anyone remember if it's a mistake or if it was intended ? In both case, "defined(_AIX)" should be added in order to make it work in all AIX versions or with all AIX compilers. Thanks,
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003506) christos    2020-12-16 23:42	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
209	[file] General	crash	always	2020-11-13 10:44	2020-12-16 23:38
Reporter:	Helflym	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	apprentice.c:coalesce_entries can call malloc with a 0 size
Description:	Hi, When running "regex-eol", it happens that coalesce_entries is called with "nme = 0". Thus, "mentrycount" will be 0 and the malloc for "**ma" will be called with "slen = 0". In most of the OSes, it does work and will return a pointer, but on AIX, it's not allowed and will raise a ENOMEM error. I've made a patch to avoid calling coalesce_entries if there is no entries and it seems to work fine (all tests are OK). It seems the logical approach to me. But I want to be sure that it's the correct way to fix it or if it would be better to still allocate a pointer even when there is no entries, as it's done right now on Linux. Thanks,
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	file-5.39-avoid-coalesce_entries-when-there-is-no-entries.patch (457 bytes) 2020-11-13 10:44 https://bugs.astron.com/file_download.php?file_id=186&type=bug

Notes
(0003505) christos    2020-12-16 23:38	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
206	[file] General	feature	N/A	2020-10-27 19:25	2020-12-16 22:36
Reporter:	polluks	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	More IFF magic
Description:	--- iff.bak 2020-09-25 12:12:07 +0200 +++ iff 2020-10-27 00:41:15 +0100 @@ -53,6 +53,9 @@  >8 string AMFF \b, AMFF AmigaMetaFile format  >8 string WZRD \b, WZRD StormWIZARD resource  >8 string DOC\ \b, DOC desktop publishing document +>8 string SWRT \b, SWRT Final Copy/Writer document +>8 string WTXT \b, WTXT Wordworth document +>8 string WOWO \b, WOWO Wordworth document  >8 string WVQA \b, Westwood Studios VQA Multimedia,  >>24 leshort x %d video frames,  >>26 leshort x %d x
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003503) christos    2020-12-16 22:36	Applied, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
198	[file] General	block	always	2020-09-20 10:00	2020-12-15 23:58
Reporter:	Thomas	Platform:	Intel64
Assigned To:	christos	OS:	Ubuntu
Priority:	normal	OS Version:	18.04
Status:	feedback	Product Version:	5.39
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Compiling with emscripten to WebAssembly fails
Description:	I'm trying to compile libmagic to WebAssembly by using the emscripten toolchain to be able to use it in a WebExtension. It would be sufficient to get a static library. Unfortunately, the build of the library requires the execution of another target (e. g. file, to compile the magic list). This is a show stopper for emscripten, because executable targets will be WASM/JS (instead of a binary) and for sure not be executable on any build system. According to the comment in 'magic/Makefile.am' line 333 (https://github.com/file/file/blob/master/magic/Makefile.am#L333), you might already be aware of this problem. It would be nice to have a fix for this soon. If you know any workaround for this, I would appreciate it to let me know. Thanks for looking into it!
Tags:	build
Steps To Reproduce:	# setup emscripten first: https://emscripten.org/docs/getting_started/downloads.html#installation-instructions cd /tmp git clone https://github.com/file/file cd file autoreconf -i emconfigure ./configure --prefix=/tmp/file --enable-static=yes --disable-shared emmake make
Additional Information:	Error log: Making all in magic make[2]: Entering directory '/tmp/file/magic' ../src/file -C -m magic /bin/bash: ../src/file: Permission denied Makefile:831: recipe for target 'magic.mgc' failed make[2]: *** [magic.mgc] Error 126 make[2]: Leaving directory '/tmp/file/magic' Makefile:460: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/tmp/file' Makefile:369: recipe for target 'all' failed make: *** [all] Error 2
Attached Files:

Notes
(0003487) christos    2020-10-11 20:05	The file binary is built before it is being used to compile the magic database. So you are fine, you have a file binary and libmagic. Building magic.mgc can be done using a native build (and the same file will be produced). I don't really have the time to figure out the autoconf magic to make it build a native version of file in a cross-compile environment.
(0003493) Thomas    2020-10-12 04:53	Do you have a target that allows to only build libmagic (without the file binary and especially without magic.mgc)? And do you have a target or two to only build the file binary and magic.mgc?
(0003496) christos    2020-10-14 21:13	cd src && make libmagic.la cd magic && make magic.mgc cd src && make file Like that?
(0003497) Thomas    2020-10-17 17:35	Sounds promising, thank you! I cannot test it right now, but I'll give you feedback on that in several weeks and I will also post a solution for emscripten, if found.
(0003502) christos    2020-12-15 23:58	Waiting on feedback.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
203	[file] General	minor	always	2020-10-19 22:55	2020-12-15 23:57
Reporter:	vinc17	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.38
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	diff files starting with "--- prof" or "--- pipe" misidentified as CLIPPER instruction profile/trace
Description:	It seems that all files starting with "--- prof" or "--- pipe" are regarded as CLIPPER instruction profile/trace files. But such files can actually be diff files.
Tags:
Steps To Reproduce:	Consider the following file text.diff: --- profession-a 2020-10-19 11:56:36 +0000 +++ profession-b 2020-10-19 22:23:01 +0000 @@ -1,5 +1,4 @@  a -b  c  d  e $ file text.diff text.diff: CLIPPER instruction profile
Additional Information:	The issue seems to come from the fact that magic/Magdir/clipper contains: 4 string pipe CLIPPER instruction trace 4 string prof CLIPPER instruction profile
Attached Files:

Notes
(0003501) christos    2020-12-15 23:57	Commented out, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
204	[file] General	major	always	2020-10-21 03:15	2020-12-15 23:55
Reporter:	hardboy_du	Platform:
Assigned To:	christos	OS:
Priority:	high	OS Version:
Status:	feedback	Product Version:	5.39
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	visio file is recognized as application/octet-stream
Description:	> file -i test.vsdx ─╯ test.vsdx: application/octet-stream; charset=binary
Tags:
Steps To Reproduce:	visio 2019
Additional Information:
Attached Files:

Notes
(0003500) christos    2020-12-15 23:55	Do you have a sample file you can attach?

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
202	[file] General	tweak	always	2020-10-11 16:33	2020-10-11 20:28
Reporter:	osmans	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.37
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	Support Vim encryption modes
Description:	The Magic file for Vim encrypted files (i.e. /file/magic/Magdir/editors) currently only reads the first 9 bytes and not the full 12 bytes used by Vim to define its encrypted files magic numbers[1]. This issue is to request that file should read the full 12 bytes so as to identify which of the three currently supported encryption modes were used to encrypt the file. I know this doesn't meet the 16byte bar, but it's what is authoritative for Vim. Possible modes of Vim's built-in encryption are the following with their corresponding magic numbers as of Vim 8.2[2]: * zip: VimCrypt~01! * blowfish: VimCrypt~02! * blowfish2: VimCrypt~03! [1] https://github.com/vim/vim/blob/c667da5185ce5dce914d2006d62da2be0cedb384/src/crypt.c#L133 [2] https://github.com/vim/vim/blob/c667da5185ce5dce914d2006d62da2be0cedb384/src/crypt.c#L78-L131
Tags:
Steps To Reproduce:	1. Open up Vim with encryption enabled: $ vim -x hello_world.encrypted 2. Specify which encryption method to use: :set cryptmethod=blowfish2 3. Set password on the file: :set key=hunter2 4. Save and exit: :wq 5. Repeat for each supported cryptmethod and observe results of magic numbers used: $ xxd -l 12 hello_world.encrypted 00000000: 5669 6d43 7279 7074 7e30 3121 VimCrypt~01! $ xxd -l 12 hello_world2.encrypted 00000000: 5669 6d43 7279 7074 7e30 3221 VimCrypt~02! $ xxd -l 12 hello_world3.encrypted 00000000: 5669 6d43 7279 7074 7e30 3321 VimCrypt~03! I've done the reproduction in some dummy files which you can find attached to this report. All files are encrypted with the literal password "password"
Additional Information:	Here is my proposed patch: diff --git a/magic/Magdir/editors b/magic/Magdir/editors index 78f3a840..93ad2955 100644 --- a/magic/Magdir/editors +++ b/magic/Magdir/editors @@ -11,7 +11,11 @@  # Vi IMproved Encrypted file  # by David Necas <yeti@physics.muni.cz> +# updated by Osman Surkatty  0 string VimCrypt~ Vim encrypted file data +>9 string 01! with zip cryptmethod +>9 string 02! with blowfish cryptmethod +>9 string 03! with blowfish2 cryptmethod  0 name vimnanoswap  >67 byte 0
Attached Files:	hello_world3.encrypted (41 bytes) 2020-10-11 16:33 https://bugs.astron.com/file_download.php?file_id=180&type=bug hello_world.encrypted (25 bytes) 2020-10-11 16:33 https://bugs.astron.com/file_download.php?file_id=182&type=bug hello_world2.encrypted (41 bytes) 2020-10-11 16:33 https://bugs.astron.com/file_download.php?file_id=181&type=bug vim_magic.patch (461 bytes) 2020-10-11 16:36 https://bugs.astron.com/file_download.php?file_id=183&type=bug

Notes
(0003486) osmans    2020-10-11 16:36	Attaching patch file.
(0003492) christos    2020-10-11 20:28	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
197	[file] General	minor	N/A	2020-09-11 04:49	2020-10-11 20:26
Reporter:	factoreal	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	Be File System (bfs) file recognition
Description:	Hi all, I don't know here is the right place for suggesting a new file type, but I do it and I hope it's useful. When I was working on some file systems in the forensics lab, I noticed that the BFS file system has not been detected by file. According to the [Wikipedia] page: >> The Be File System (BFS) is the native file system for the BeOS. In the Linux kernel, it is referred to as "BeFS" to avoid confusion with Boot File System. So I decided to report this as an issue. Generating a BFS file image is very easy: $ sudo dd if=/dev/random of=my_bfs.img bs=1M count=50 $ sudo mkfs.bfs my_bfs.img Again reviewing the BFS file structure [here], we can find that the magic number is `1BADFACE'. Hence adding the BFS file type to the file magic header list is very straightforward. Regards [Wikipedia]:https://en.wikipedia.org/wiki/Be_File_System [here]:http://martin.hinner.info/fs/bfs/bfs-structure.html
Tags:	bfs, file system
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003485) polluks    2020-10-09 08:28	Attention! You mixed two different file systems, please read your own quote! BEFS_SUPER_MAGIC1 = 0x42465331, /* BFS1 */ BEFS_SUPER_MAGIC2 = 0xdd121031, BEFS_SUPER_MAGIC3 = 0x15b6830e,
(0003491) christos    2020-10-11 20:26	Added both.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
201	[file] General	text	always	2020-10-04 11:50	2020-10-11 20:14
Reporter:	ferivoz	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	Typo in manual page
Description:	compatibility instead of compatilibity ---  doc/file.man | 2 +-  1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/file.man b/doc/file.man index afba71e..c90e3ac 100644 --- a/doc/file.man +++ b/doc/file.man @@ -236,7 +236,7 @@ Like  but ignore tests that  .Nm  does not know about. -This is intended for compatilibity with older versions of +This is intended for compatibility with older versions of  .Nm .  .It Fl Fl extension  Print a slash-separated list of valid extensions for the file type found. -- 2.28.0
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003490) christos    2020-10-11 20:14	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
199	[file] General	feature	N/A	2020-09-25 07:58	2020-10-11 20:12
Reporter:	polluks	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	MovieSetter support
Description:	--- g:file/magic/Magdir/animation 2020-06-19 14:19:13 +0200 +++ animation 2020-09-25 02:35:30 +0200 @@ -905,12 +905,16 @@  >0x42 ubeshort 0 no audio  >0x42 ubeshort >0 %dHz audio   -# From: "Stefan A. Haubenthal" <polluks@web.de> +# From: Stefan A. Haubenthal <polluks@sdf.lonestar.org>  0 string DVDVIDEO-VTS Video title set,  >0x21 byte x v%x  0 string DVDVIDEO-VMG Video manager,  >0x21 byte x v%x   +# From: Stefan A. Haubenthal <polluks@sdf.lonestar.org> +0 string xMovieSetter MovieSetter movie +0 string xSceneEditor MovieSetter movie +  # From: Behan Webster <behanw@websterwood.com>  # NuppelVideo used by Mythtv (*.nuv)  # Note: there are two identical stanzas here differing only in the
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003489) christos    2020-10-11 20:12	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
200	[file] General	feature	N/A	2020-09-25 10:17	2020-10-11 20:07
Reporter:	polluks	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	Fantavision support
Description:	--- iff.bak 2020-06-19 14:19:13 +0200 +++ iff 2020-09-25 12:12:07 +0200 @@ -41,6 +41,7 @@  >8 string ANIM \b, ANIM animation  >8 string YAFA \b, YAFA animation  >8 string SSA\ \b, SSA super smooth animation +>8 string FANT \b, Fantavision animation  >8 string ACBM \b, ACBM continuous image  >8 string FAXX \b, FAXX fax image  # other formats
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003488) christos    2020-10-11 20:07	added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
191	[file] General	feature	N/A	2020-08-26 13:37	2020-09-09 23:22
Reporter:	vinc17	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	differentiate git commits and git commit logs
Description:	A file starting with "commit " followed by a hash can be one of the various kinds of Git files. In particular, it can be: 1. a single commit with diff output, e.g. what "git show" outputs; 2. a git commit log, e.g. what "git log" outputs (there may also be various kinds of stats, such as with --stat); 3. a git commit log with diff output, e.g. what "git log --patch" outputs. (1) and (2) are common. (3), which consists of a sequence of commits like in (2), but each one (except merge commits) with a diff like in (1), is possible, but I think that I've never seen it in practice. For all of them, "file" outputs a description of the form "Git commit <hash>". This is particularly misleading for commit log files (2) as such files almost always contain several commits (thus several hashes). It should at least differentiate (1) and (2). Differentiating (3) from (1) is possible by reading a sufficient number of bytes, and I think that this is OK as this can be controlled by the end user with option -P (--parameter). In the case the first line has the form "commit <hash>", I suggest to change the tests to output (depending on what one wishes for a single commit with no diff output): 1. If there are no lines starting with "diff ", output "Git commit log". 2. If there is another line of the form "commit <hash>", output "Git commit log with diff output". 3. Otherwise output "Git commit <hash>". or 1. If there isn't another line of the form "commit <hash>", output "Git commit <hash>". 2. If there are no lines starting with "diff ", output "Git commit log". 3. Otherwise output "Git commit log with diff output". where <hash> in the output is the hash obtained in the first line (which is what "file" currently gives). Note: I think that if there is a diff, a "diff " line will occur in the first non-merge commit, so that there is room for optimization.
Tags:
Steps To Reproduce:	On a git repository, check the output with: $ git show $ git log $ git log --patch
Additional Information:
Attached Files:	commit-log.txt (289 bytes) 2020-09-09 23:22 https://bugs.astron.com/file_download.php?file_id=177&type=bug commit-log-with-diff.txt (523 bytes) 2020-09-09 23:22 https://bugs.astron.com/file_download.php?file_id=178&type=bug single-commit.txt (261 bytes) 2020-09-09 23:22 https://bugs.astron.com/file_download.php?file_id=179&type=bug

Notes
(0003481) christos    2020-09-06 14:54	I don't see any such files, can you post some examples?
(0003484) vinc17    2020-09-09 23:22	I have added the 3 cases: 1. single-commit.txt (a single commit with diff output: what "git show" outputs) 2. commit-log.txt (a git commit log: what "git log" outputs) 3. commit-log-with-diff.txt (a git commit log with diff output: what "git log --patch" outputs)

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
187	[file] General	feature	have not tried	2020-08-24 02:36	2020-09-06 15:17
Reporter:	joveler	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	Support ALZ, EGG archive format
Description:	Please include the ALZ/EGG archive format signature. ALZ and EGG archive format was created by ESTSoft, Inc. ESTSoft's ALZip* software was a de-facto archive tool in Korea, making ALZ/EGG format somewhat prevalent on the Korean web. *: https://en.wikipedia.org/wiki/ALZip I have attached the diff file which contains a signature of ALZ and EGG archive format, and sample files for test.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	0001-Add-ALZ-EGG-archive-signature.patch (898 bytes) 2020-08-24 02:36 https://bugs.astron.com/file_download.php?file_id=156&type=bug Samples.alz (999 bytes) 2020-08-24 02:36 https://bugs.astron.com/file_download.php?file_id=157&type=bug Samples.egg (1,417 bytes) 2020-08-24 02:36 https://bugs.astron.com/file_download.php?file_id=158&type=bug Samples.zip (2,049 bytes) 2020-08-24 02:36 https://bugs.astron.com/file_download.php?file_id=159&type=bug 0001-Add-ALZ-EGG-archive-signature-2.patch (1,221 bytes) 2020-08-31 02:43 https://bugs.astron.com/file_download.php?file_id=171&type=bug

Notes
(0003469) neal    2020-08-28 15:12	I took a brief look at the patch and the signature is surprisingly small (3 bytes for alz files and 4 bytes for egg files). Is there no other relatively fixed data available? Perhaps a field with a version number?
(0003470) joveler    2020-08-31 02:43	@neal I have updated the EGG format signature by adding a version and split/solid archive detection. The ALZ format, however, does not have any official file format document. As such, it is only possible by the reading the source of unalz (thrid party decompressor), which would take some time. In the meantime, I have changed its magic to `ALZ\001` from `ALZ` to avoid misidentification of text files.
(0003483) christos    2020-09-06 15:17	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
195	[file] General	minor	have not tried	2020-09-01 10:19	2020-09-05 17:39
Reporter:	neal	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	Different execution depending on whether or not --mime-type is given
Description:	Consider the following magic file: 0 byte x >0 use foo >>0 byte x 1 >>0 use bar 0 name foo >0 byte x 2 0 name bar >0 byte x 3 !:mime application/3 When I run it (using file 5.35 from Debian or the latest from github.com/file/file), I see the following: $ file -m /tmp/mime.magic /tmp/byte.bin /tmp/byte.bin: 2 1 3 us@grit:~/neal/src/file$ file --mime-type -m /tmp/mime.magic /tmp/byte.bin /tmp/byte.bin: application/octet-stream What I'd expect is the following: $ src/file --mime-type -m /tmp/mime.magic /tmp/byte.bin /tmp/byte.bin: application/3 $ src/file -m /tmp/mime.magic /tmp/byte.bin /tmp/byte.bin: 2 1 3 The problem is that after executing foo, match sets *returnval to 0 when --mime-type is specified and 1 when it is not. AIUI, *returnval basically means: "we printed something." When --mime-type is specified, the magic entries in foo don't have any mime information, so nothing is printed and *returnvalue is 0. When --mime-type is not specified, the descriptions are printed, so something is printed and *returnval is 1. This causes mget to behave differently: for FILE_USE, it returns *return_value.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	mime.magic (116 bytes) 2020-09-01 10:19 https://bugs.astron.com/file_download.php?file_id=173&type=bug byte.bin (256 bytes) 2020-09-01 10:19 https://bugs.astron.com/file_download.php?file_id=174&type=bug 0005-Change-mget-to-return-whether-a-USE-execute-not-whet.patch (1,716 bytes) 2020-09-01 12:19 https://bugs.astron.com/file_download.php?file_id=175&type=bug

Notes
(0003471) neal    2020-09-01 11:53	I've spent some time studying the code and I think the correct solution is to change mget so that FILE_USE behaves like the other entry types. Reading mget, it appears that -1 is returned if there is an error, 0 is returned if the accessed data is not buffered, and 1 is returned if the data could be read. I've tried to figure out what match's return type means, but it seems to depend on many conditions. I think it does the following: If match returns -1, then an error occured. If an annotation was handled, it returns 1. If cont_level is 0 and an offset is used (OFFADD), it returns 0. Otherwise, it returns *returnval. *returnval can be set by mget or set directly. When set directly, it is set to 1. This is done if mget returns 1 and type is FILE_INDIRECT, if handle_annotation returns an error (-1) or success (1), or if something is displayed. mget only changes returnval insofar as it passes returnval to match when the magic entry's type is FILE_USE. As a first approximation, it seems that mget with FILE_USE is returning whether the procedure matched whereas in other cases, mget is only returning whether the data could be loaded. The match case should actually be handled by magiccheck, and, to align FILE_USE's behavior with other types, this should only return whether the use "executed." My attached patch changes the behavior of mget. In issue 0000190 (https://bugs.astron.com/view.php?id=190), I fixed magiccheck.
(0003480) christos    2020-09-05 17:39	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
194	[file] General	minor	always	2020-08-31 10:10	2020-09-05 17:20
Reporter:	puchuu	Platform:	*-linux-musl
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	Missing seccomp whitelist entries for musl libc
Description:	Musl libc uses system calls different from whitelisted in seccomp.c. Please test file on musl system too.
Tags:
Steps To Reproduce:	Compile file and try to launch it.
Additional Information:	Please visit https://bugs.gentoo.org/730540
Attached Files:	seccomp.patch (750 bytes) 2020-08-31 10:10 https://bugs.astron.com/file_download.php?file_id=172&type=bug

Notes
(0003478) christos    2020-09-05 17:20	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
193	[file] General	minor	have not tried	2020-08-27 19:47	2020-09-05 17:17
Reporter:	neal	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	use incorrectly resets the offset
Description:	Consider the following magic file: 0 byte x >&10 byte x 1:%d >>&10 byte x 2:%d >&20 use foo >>&10 byte x 3:%d 0 name foo >&200 byte x 4:%d I would expect it to print: /tmp/byte.bin: 1:11 2:22 4:221 3:31 but it actually prints: /tmp/byte.bin: 1:11 2:22 4:221 3:10 It appears that when a 'use' returns, it does not reset ms->offset to the parent continuation's offset.
Tags:
Steps To Reproduce:	$ file -d -m /tmp/offset.magic /tmp/byte.bin unknown, 0: Warning: using regular magic file `/tmp/offset.magic' (no description): binary (no description): text [try zmagic 0] [try tar 0] [try json 0] [try cdf 0] [try elf 0] bb=[0x7f3ab19bb010,256], 0 [b=0x7f3ab19bb010,256], [o=0, c=0] mget(type=1, flag=0x20, offset=0, o=0, nbytes=256, il=0, nc=0) mget/96 @0: \000\001\002\003\004\005\006\a\b\t\n\v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_ 1: > 0 byte&,x,""] 0 == *any* = 1 bb=[0x7f3ab19bb010,256], 10 [b=0x7f3ab19bb010,256], [o=0xa, c=1] mget(type=1, flag=0x2, offset=11, o=0, nbytes=256, il=0, nc=0) mget/96 @11: \v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghij 2: >> 10 byte&,x,"1:%d"] 11 == *any* = 1 bb=[0x7f3ab19bb010,256], 10 [b=0x7f3ab19bb010,256], [o=0xa, c=2] mget(type=1, flag=0x2, offset=22, o=0, nbytes=256, il=0, nc=0) mget/96 @22: \026\027\030\031\032\033\034\035\036\037 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstu 3: >>> 10 byte&,x,"2:%d"] 22 == *any* = 1 bb=[0x7f3ab19bb010,256], 20 [b=0x7f3ab19bb010,256], [o=0x14, c=1] mget(type=46, flag=0x2, offset=21, o=0, nbytes=256, il=0, nc=0) mget/96 @21: \025\026\027\030\031\032\033\034\035\036\037 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrst 4: >> 20 use,='foo',""] bb=[0x7f3ab19bb010,256], 0 [b=0x7f3ab19bb010,256], [o=0, c=0] mget(type=45, flag=0, offset=0, o=21, nbytes=256, il=0, nc=1) mget/96 @0: \025\026\027\030\031\032\033\034\035\036\037 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrst 7: > 0 name,='foo',""] bb=[0x7f3ab19bb010,256], 200 [b=0x7f3ab19bb010,256], [o=0xc8, c=1] mget(type=1, flag=0x2, offset=200, o=21, nbytes=256, il=0, nc=1) mget/96 @200: \335\336\337\340\341\342\343\344\345\346\347\350\351\352\353\354\355\356\357\360\361\362\363\364\365\366\367\370\371\372\373\374\375\376\377\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000 8: >> 200 byte&,x,"4:%d"] 18446744073709551581 == *any* = 1 bb=[0x7f3ab19bb010,256], 10 [b=0x7f3ab19bb010,256], [o=0xa, c=2] mget(type=1, flag=0x2, offset=10, o=0, nbytes=256, il=0, nc=0) mget/96 @10: \n\v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghi 5: >>> 10 byte&,x,"3:%d"] 10 == *any* = 1 [try softmagic 1] /tmp/byte.bin: 1:11 2:22 4:221 3:10
Additional Information:
Attached Files:	offset.magic (105 bytes) 2020-08-27 19:47 https://bugs.astron.com/file_download.php?file_id=168&type=bug byte.bin (256 bytes) 2020-08-27 19:47 https://bugs.astron.com/file_download.php?file_id=169&type=bug 0004-Save-ms-offset-around-calls-to-use.patch (1,505 bytes) 2020-08-28 13:01 https://bugs.astron.com/file_download.php?file_id=170&type=bug

Notes
(0003467) neal    2020-08-27 20:27	Another example: 0 byte x >&10 byte x 1:%d >>&10 byte x 2:%d >&10 byte x 3:%d >>&20 use foo >>>&10 byte x 4:%d >&10 byte x 5:%d 0 name foo >&200 byte x 6:%d $ file -m /tmp/offset.magic /tmp/byte.bin /tmp/byte.bin: 1:11 2:22 3:11 6:232 4:10 5:10 Since we have "4:10", it appears that not only is the parent continuation's offset ignored, but the offset is reset to 0.
(0003468) neal    2020-08-28 13:01	The attached patch appears to fix the problem: $ src/file -d -m /tmp/offset.magic /tmp/byte.bin unknown, 0: Warning: using regular magic file `/tmp/offset.magic' (no description): binary (no description): text [try zmagic 0] [try tar 0] [try json 0] [try csv 0] [try cdf 0] [try elf 0] bb=[0x7f6d3cd7c010,256,0], 0 [b=0x7f6d3cd7c010,256,0], [o=0, c=0] mget(type=1, flag=0x20, offset=0, o=0, nbytes=256, il=0, nc=0) mget/128 @0: \000\001\002\003\004\005\006\a\b\t\n\v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~\177 1: > 0 byte&,x,""] 0 == *any* = 1 bb=[0x7f6d3cd7c010,256,0], 10 [b=0x7f6d3cd7c010,256,0], [o=0xa, c=1] mget(type=1, flag=0x2, offset=11, o=0, nbytes=256, il=0, nc=0) mget/128 @11: \v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~\177\200\201\202\203\204\205\206\207\210\211\212 2: >> 10 byte&,x,"1:%d"] 11 == *any* = 1 bb=[0x7f6d3cd7c010,256,0], 10 [b=0x7f6d3cd7c010,256,0], [o=0xa, c=2] mget(type=1, flag=0x2, offset=22, o=0, nbytes=256, il=0, nc=0) mget/128 @22: \026\027\030\031\032\033\034\035\036\037 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~\177\200\201\202\203\204\205\206\207\210\211\212\213\214\215\216\217\220\221\222\223\224\225 3: >>> 10 byte&,x,"2:%d"] 22 == *any* = 1 bb=[0x7f6d3cd7c010,256,0], 10 [b=0x7f6d3cd7c010,256,0], [o=0xa, c=1] mget(type=1, flag=0x2, offset=11, o=0, nbytes=256, il=0, nc=0) mget/128 @11: \v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~\177\200\201\202\203\204\205\206\207\210\211\212 4: >> 10 byte&,x,"3:%d"] 11 == *any* = 1 bb=[0x7f6d3cd7c010,256,0], 20 [b=0x7f6d3cd7c010,256,0], [o=0x14, c=2] mget(type=46, flag=0x2, offset=32, o=0, nbytes=256, il=0, nc=0) mget/128 @32: !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~\177\200\201\202\203\204\205\206\207\210\211\212\213\214\215\216\217\220\221\222\223\224\225\226\227\230\231\232\233\234\235\236\237 5: >>> 20 use,='foo',""] bb=[0x7f6d3cd7c010,256,0], 0 [b=0x7f6d3cd7c010,256,0], [o=0, c=0] mget(type=45, flag=0, offset=0, o=32, nbytes=256, il=0, nc=1) mget/128 @0: !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~\177\200\201\202\203\204\205\206\207\210\211\212\213\214\215\216\217\220\221\222\223\224\225\226\227\230\231\232\233\234\235\236\237 9: > 0 name,='foo',""] bb=[0x7f6d3cd7c010,256,0], 200 [b=0x7f6d3cd7c010,256,0], [o=0xc8, c=1] mget(type=1, flag=0x2, offset=200, o=32, nbytes=256, il=0, nc=1) mget/128 @200: \350\351\352\353\354\355\356\357\360\361\362\363\364\365\366\367\370\371\372\373\374\375\376\377\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000 10: >> 200 byte&,x,"6:%d"] 18446744073709551592 == *any* = 1 bb=[0x7f6d3cd7c010,256,0], 10 [b=0x7f6d3cd7c010,256,0], [o=0xa, c=3] mget(type=1, flag=0x2, offset=42, o=0, nbytes=256, il=0, nc=0) mget/128 @42: *+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~\177\200\201\202\203\204\205\206\207\210\211\212\213\214\215\216\217\220\221\222\223\224\225\226\227\230\231\232\233\234\235\236\237\240\241\242\243\244\245\246\247\250\251 6: >>>> 10 byte&,x,"4:%d"] 42 == *any* = 1 bb=[0x7f6d3cd7c010,256,0], 10 [b=0x7f6d3cd7c010,256,0], [o=0xa, c=1] mget(type=1, flag=0x2, offset=11, o=0, nbytes=256, il=0, nc=0) mget/128 @11: \v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~\177\200\201\202\203\204\205\206\207\210\211\212 7: >> 10 byte&,x,"5:%d"] 11 == *any* = 1 [try softmagic 1] /tmp/byte.bin: 1:11 2:22 3:11 6:232 4:42 5:11 Also, it fixes the value of line 7 (which I had overlooked): it should be 5:11, not 5:10.
(0003477) christos    2020-09-05 17:17	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
190	[file] General	minor	have not tried	2020-08-26 13:02	2020-09-05 14:58
Reporter:	neal	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	use always matches
Description:	Consider the following: 0 byte x 1 >0 use foo >>0 byte x 2 0 name foo >0 byte =1 3 I would expect this to print: $ src/file -m /tmp/use.magic /tmp/byte.bin /tmp/byte.bin: 1 But, it does the following: $ src/file -m /tmp/use.magic /tmp/byte.bin /tmp/byte.bin: 1 2 This is because magiccheck (softmagic.c:2240) always returns 1 when determining whether a USE or NAME matched. I have some magic code that finds the start of a block of data and then checks whether the data has the required signature. I wanted to use a 'use foo' to check the data. But, that doesn't work, because the 'use foo' doesn't fail.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	use.magic (61 bytes) 2020-08-26 13:02 https://bugs.astron.com/file_download.php?file_id=164&type=bug byte.bin (256 bytes) 2020-08-26 13:02 https://bugs.astron.com/file_download.php?file_id=165&type=bug 0002-Change-use-to-only-return-true-if-its-sub-continuati.patch (4,008 bytes) 2020-08-26 20:30 https://bugs.astron.com/file_download.php?file_id=166&type=bug

Notes
(0003465) neal    2020-08-26 20:30	The attached patch fixes the above issue. It changes 'use' to act like the body of the named continuation were pasted in its place.
(0003466) neal    2020-08-26 20:31	The above patch should probably only be applied if https://bugs.astron.com/view.php?id=189 is also applied.
(0003476) christos    2020-09-05 14:58	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
192	[file] General	minor	have not tried	2020-08-26 20:45	2020-09-05 14:31
Reporter:	neal	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	Typo in magic file
Description:	msooxml contains a pretty obvious typo: like the other formats, the visio match should be a subcontinuation, not a top-level continuation. (Note: I haven't tested this.)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	0003-Fix-magic.patch (885 bytes) 2020-08-26 20:45 https://bugs.astron.com/file_download.php?file_id=167&type=bug

Notes
(0003475) christos    2020-09-05 14:31	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
188	[file] General	minor	always	2020-08-26 08:37	2020-09-05 14:28
Reporter:	neal	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	nested use of name is unexpected
Description:	file doesn't handle non-top level "name" directives well.
Tags:
Steps To Reproduce:	Consider the following magic file (also attached): 0 byte x 1 >0 name foo >>0 byte x in foo >0 byte x 2 >0 use foo If this successfully parses, then I'd expect the 'use foo' to succeed. Instead, it executes from top to bottom *including the body of foo*, and then fails at the 'use foo' line. See the trace below. I can understand not wanting the complexity that non-top level named continuations would introduce. But, in that case, I think the parse should reject files that have named continuations that are not at the top level.
Additional Information:	$ file -d -m /tmp/nested-name.magic /tmp/byte.bin unknown, 0: Warning: using regular magic file `/tmp/nest-name.magic' 1: binary [try zmagic 0] [try tar 0] [try json 0] [try cdf 0] [try elf 0] bb=[0x7f227cca8010,256], 0 [b=0x7f227cca8010,256], [o=0, c=0] mget(type=1, flag=0x20, offset=0, o=0, nbytes=256, il=0, nc=0) mget/96 @0: \000\001\002\003\004\005\006\a\b\t\n\v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_ 1: > 0 byte&,x,"1"] 0 == *any* = 1 bb=[0x7f227cca8010,256], 0 [b=0x7f227cca8010,256], [o=0, c=1] mget(type=45, flag=0, offset=0, o=0, nbytes=256, il=0, nc=0) mget/96 @0: \000\001\002\003\004\005\006\a\b\t\n\v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_ 2: >> 0 name,='foo',""] bb=[0x7f227cca8010,256], 0 [b=0x7f227cca8010,256], [o=0, c=2] mget(type=1, flag=0, offset=0, o=0, nbytes=256, il=0, nc=0) mget/96 @0: \000\001\002\003\004\005\006\a\b\t\n\v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_ 3: >>> 0 byte&,x,"in foo"] 0 == *any* = 1 bb=[0x7f227cca8010,256], 0 [b=0x7f227cca8010,256], [o=0, c=1] mget(type=1, flag=0, offset=0, o=0, nbytes=256, il=0, nc=0) mget/96 @0: \000\001\002\003\004\005\006\a\b\t\n\v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_ 4: >> 0 byte&,x,"2"] 0 == *any* = 1 bb=[0x7f227cca8010,256], 0 [b=0x7f227cca8010,256], [o=0, c=1] mget(type=46, flag=0, offset=0, o=0, nbytes=256, il=0, nc=0) mget/96 @0: \000\001\002\003\004\005\006\a\b\t\n\v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_ 4: >> 0 use,='foo',""] [try softmagic -1] /tmp/byte.bin: ERROR: 1 in foo 2 cannot find entry `foo'
Attached Files:	nested-name.magic (63 bytes) 2020-08-26 08:37 https://bugs.astron.com/file_download.php?file_id=160&type=bug 0001-Fix-use.patch (10,365 bytes) 2020-08-26 12:12 https://bugs.astron.com/file_download.php?file_id=163&type=bug

Notes
(0003464) neal    2020-08-26 12:12	This fixes the issue for me. I've tried to make the changes as non-invasive as possible.
(0003474) christos    2020-09-05 14:28	Fixed, thanks! mag2, 2: Warning: `name foo' entries can only be declared at top level

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
189	[file] General	minor	have not tried	2020-08-26 10:44	2020-09-05 14:17
Reporter:	neal	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	'use' corrupts 'ms->c'
Description:	Consider the following magic file: 10 byte x >&0 byte x 1:%d >&0 use foo >&0 byte x 2:%d 20 name foo >&30 byte x 3:%d I would expect this to output: /tmp/byte.bin: 1:11 3:41 2:11 instead, it outputs /tmp/byte.bin: 1:11 3:41 2:0 Commenting out line 3 ('use foo') causes line 4 to correctly output 2:11. According to my analysis, this happens, because when mget handles a FILE_USE entry (around line 'softmagic.c:1890') , it recursively calls 'match' with the same magic_set ('ms'). 'match' sets 'cont_level' to 0, and initializes 'ms->c[0]'. Unfortunately, and 'match' doesn't restore it before returning. (In fact, it has to restore the whole continuation level.) I suspect that the easiest fix would be to turn 'ms->c' into a stack and each time 'match' is used, a new continuation array is pushed. Then before 'match' returns, it pops off the top continuation array.
Tags:
Steps To Reproduce:	$ file -d -m /tmp/cont_level.magic /tmp/byte.bin unknown, 0: Warning: using regular magic file `/tmp/cont_level.magic' (no description): binary (no description): text [try zmagic 0] [try tar 0] [try json 0] [try cdf 0] [try elf 0] bb=[0x7f1ab5c42010,256], 10 [b=0x7f1ab5c42010,256], [o=0xa, c=0] mget(type=1, flag=0x20, offset=10, o=0, nbytes=256, il=0, nc=0) mget/96 @10: \n\v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghi 1: > 10 byte&,x,""] 10 == *any* = 1 bb=[0x7f1ab5c42010,256], 0 [b=0x7f1ab5c42010,256], [o=0, c=1] mget(type=1, flag=0x2, offset=11, o=0, nbytes=256, il=0, nc=0) mget/96 @11: \v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghij 2: >> 0 byte&,x,"1:%d"] 11 == *any* = 1 bb=[0x7f1ab5c42010,256], 0 [b=0x7f1ab5c42010,256], [o=0, c=1] mget(type=46, flag=0x2, offset=11, o=0, nbytes=256, il=0, nc=0) mget/96 @11: \v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghij 3: >> 0 use,='foo',""] bb=[0x7f1ab5c42010,256], 20 [b=0x7f1ab5c42010,256], [o=0x14, c=0] mget(type=45, flag=0, offset=20, o=11, nbytes=256, il=0, nc=1) mget/96 @20: \037 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~ 6: > 20 name,='foo',""] bb=[0x7f1ab5c42010,256], 30 [b=0x7f1ab5c42010,256], [o=0x1e, c=1] mget(type=1, flag=0x2, offset=30, o=11, nbytes=256, il=0, nc=1) mget/96 @30: )*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~\177\200\201\202\203\204\205\206\207\210 7: >> 30 byte&,x,"3:%d"] 41 == *any* = 1 bb=[0x7f1ab5c42010,256], 0 [b=0x7f1ab5c42010,256], [o=0, c=1] mget(type=1, flag=0x2, offset=0, o=0, nbytes=256, il=0, nc=0) mget/96 @0: \000\001\002\003\004\005\006\a\b\t\n\v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_ 4: >> 0 byte&,x,"2:%d"] 0 == *any* = 1 [try softmagic 1] /tmp/byte.bin: 1:11 3:41 2:0
Additional Information:
Attached Files:	cont_level.magic (84 bytes) 2020-08-26 10:44 https://bugs.astron.com/file_download.php?file_id=161&type=bug byte.bin (256 bytes) 2020-08-26 10:44 https://bugs.astron.com/file_download.php?file_id=162&type=bug

Notes
(0003473) christos    2020-09-05 14:17	Nice catch! Thanks.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
137	[file] General	minor	always	2020-02-02 04:02	2020-08-25 01:29
Reporter:	Kid	Platform:	x86_64
Assigned To:	christos	OS:	Linux (Arch)
Priority:	normal	OS Version:	5.4.2
Status:	feedback	Product Version:	5.37
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	MP4 Video File Incorrectly Identified as Audio
Description:	■ xxd 2020-01-22.mp4 | head 00000000: 0000 001c 6674 7970 4d53 4e56 0100 2500 ....ftypMSNV..%. 00000010: 4d53 4e56 6973 6f6d 6d70 3432 0000 0008 MSNVisommp42.... 00000020: 6672 6565 3c0f b333 6d64 6174 0001 a2fd free<..3mdat.... 00000030: 65b8 0400 2fec 2ddd ec5c d873 95cc 4bcf e.../.-..\.s..K. 00000040: 9fec c7a1 dca9 43a1 0271 55e5 28cc 0390 ......C..qU.(... 00000050: f052 bed2 5546 08ce e157 00bb 48c8 effc .R..UF...W..H... 00000060: d3ef d4ec 9de9 ae80 b81d 6eee 01ca 9888 ..........n..... 00000070: 92a2 197e c781 1e86 49d9 d9af 70aa c58a ...~....I...p... 00000080: 2987 184d 017c 2a01 b058 bde5 4780 3abb )..M.|*..X..G.:. 00000090: d3e2 332a 96f4 da91 8236 7ece 5334 4c6e ..3*.....6~.S4Ln ■ ffprobe -hide_banner 2020-01-22.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '2020-01-22.mp4':   Metadata:     major_brand : MSNV     minor_version : 16786688     compatible_brands: MSNVisommp42     creation_time : 2020-01-22T13:59:53.000000Z     title :     artist :     album :     date :     track : 0     genre :     comment :   Duration: 00:43:10.96, start: 0.033356, bitrate: 3115 kb/s     Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 2983 kb/s, 29.97 fps, 29.97 tbr, 30k tbn, 59.94 tbc (default)     Metadata:       creation_time : 2020-01-22T13:59:53.000000Z       handler_name : Video Media Handler       encoder : AVC Coding     Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 127 kb/s (default)     Metadata:       creation_time : 2020-01-22T13:59:53.000000Z       handler_name : Sound Media Handler ■ file --mime-type -Lb 2020-01-22.mp4 audio/mp4 ■ file --mime-type -l 2020-01-22.mp4 Set 0: Binary patterns: Strength = 500@47: Biosig/Brainvision Marker file [biosig/brainvision] Strength = 490@122: Biosig/TMSiLOG [biosig/tmsilog] Strength = 461@127: Biosig/SYNERGY [biosig/synergy] Strength = 460@46: Biosig/Brainvision V-Amp file [] Strength = 410@45: Biosig/Brainvision data file [] Strength = 380@6: OpenSSH private key [] Strength = 361@107: EICAR virus test files [] Strength = 360@19: Biosig/ATES MEDICA SOFT. EEG for Windows [biosig/ates] Strength = 350@188: SketchUp Model [application/vnd.sketchup.skp] Strength = 340@618: sc68 Atari ST music [] Strength = 340@35: T64 tape Image [] Strength = 340@40: T64 tape Image [] Strength = 340@19: Erlang JAM file - version 4.3 [] Strength = 340@51: Mathematica binary file [] Strength = 340@695: %s [application/vnd.ms-excel] Strength = 340@66: Bazaar merge directive [] Strength = 340@92: SQLite 2.x database [] Strength = 340@136: Paged COBALT boot rom [] Strength = 331@280: NetImmerse game engine file [] Strength = 330@1540: LyNX archive [] Strength = 330@49: FrameMaker IPL file [application/x-mif] Strength = 330@267: Gamebryo game engine file [] Strength = 330@61: PGP public key block [application/pgp-keys] Strength = 320@361: %s [] Strength = 320@333: SNES SPC700 sound file [] Strength = 320@8: BinHex binary text [application/mac-binhex40] Strength = 320@689: %s [application/vnd.ms-excel] Strength = 320@27: old timezone data [] Strength = 320@28: old timezone data [] Strength = 320@29: old timezone data [] Strength = 320@30: old timezone data [] Strength = 320@31: old timezone data [] Strength = 320@32: old timezone data [] Strength = 310@16: Erlang JAM file - version 4.2 [] Strength = 310@17: Erlang JAM file - version 4.2 [] Strength = 310@16: PostScript Type 1 font text [] Strength = 310@83: Caris ASCII project summary [] Strength = 310@7: old ACE/gr binary file [] Strength = 310@752: InnoSetup Log [application/x-innosetup] Strength = 300@273: Gamebryo game engine animation File [] Strength = 300@18: Mathematica notebook [] Strength = 300@650: %s [application/msword] Strength = 300@59: Subversion dumpfile [] Strength = 300@9: PEM certificate [] Strength = 290@203: %s [] Strength = 290@20: FGDC ASCII metadata [] Strength = 290@652: Spanish Microsoft Word 6 document data [application/msword] Strength = 290@65: Bazaar Bundle [] Strength = 290@10: PEM certificate request [] Strength = 280@994: NUT multimedia container [] Strength = 280@1230: shell archive text [application/octet-stream] Strength = 280@12: Clojure script text executable [text/x-clojure] Strength = 280@104: AVG 7 Antivirus vault file data [] Strength = 280@20: ACE/gr fit description file [] Strength = 280@950: Paint Shop Pro Image File [] Strength = 280@69: PGP signature [application/pgp-signature] Strength = 271@382: Windows Registry text (Win2K or above) [text/x-ms-regedit] Strength = 270@119: Biosig/TMS32 [biosig/tms32] Strength = 270@2389: floppy image data (ApriDisk) [] Strength = 270@178: Quake I save: ddm4 East side invertationa [] Strength = 270@196: Linux S390 [] Strength = 270@68: Mathematica 3.0 notebook [] Strength = 270@64: abook address book [application/x-abook-addressbook] Strength = 270@642: AAF legacy file using MS Structured Storage [] Strength = 270@645: AAF file using MS Structured Storage [] Strength = 270@58: Microsoft Roslyn C# debugging symbols version 1.0 [] Strength = 270@10: Netscape Address book [] Strength = 270@14: PEM ECDSA private key [] Strength = 261@61: GCOV coverage report [] Strength = 260@667: Guitar Pro Ver. 3 Tablature [] Strength = 260@950: Junglevision instrument data [] Strength = 260@20: Clojure script text executable [text/x-clojure] Strength = 260@645: Mozilla Mork database [] Strength = 260@39: Kate swap file [] Strength = 260@164: Quake I save: d7 The incinerator plant [] Strength = 260@168: Quake I save: d12 Takahiro laboratories [] Strength = 260@12: ACE/gr ascii file [] Strength = 260@7: NASA SPICE file (transfer format) [] Strength = 260@16: Netscape folder cache [] Strength = 260@7: NetWare Loadable Module [] Strength = 260@65: PGP message [application/pgp] Strength = 260@251: Freeplane document [application/x-freeplane] Strength = 260@257: Scribus Document [application/x-scribus] Strength = 250@146: GUS patch [] Strength = 250@147: Old GUS patch [] Strength = 250@603: %s [] Strength = 250@84: Biosig/Galileo [biosig/galileo] Strength = 250@147: Biosig/File exchange format (FEF) [biosig/fef] Strength = 250@16: Clojure script text executable [text/x-clojure] Strength = 250@79: Bourne-Again shell script executable (binary data) [text/x-shellscript] Strength = 250@12: Diamond Multimedia Document [] Strength = 250@125: FreeBSD/i386 a.out core file [] Strength = 250@87: Quake I save: e1m1 The slipgate complex [] Strength = 250@88: Quake I save: e1m2 Castle of the damned [] Strength = 250@101: Quake I save: e2m6 The dismal oubliette [] Strength = 250@105: Quake I save: e3m4 Satan's dark delight [] Strength = 250@110: Quake I save: e4m2 The tower of despair [] Strength = 250@111: Quake I save: e4m3 The elder god shrine [] Strength = 250@117: Quake I save: end Shub-Niggurath's pit [] Strength = 250@137: Quake I save: hip2m6 The gremlin's domain (secret) [] Strength = 250@145: Quake I save: hipdm1 The edge of oblivion (secret) [] Strength = 250@175: Quake I save: ddm1 The seventh precinct [] Strength = 250@65: CLISP byte-compiled Lisp program text [] Strength = 250@31: Maple worksheet, but weird [] Strength = 250@11: PEM RSA private key [] Strength = 250@12: PEM DSA private key [] Strength = 250@302: Bochs disk image, [] Strength = 250@397: WINE registry text [] Strength = 240@8: Clojure script text executable [text/x-clojure] Strength = 240@305: Adobe Multiple Master font [] Strength = 240@306: Adobe Multiple Master font [] Strength = 240@94: Quake I save: e1m7 The house of Chthon [] Strength = 240@102: Quake I save: e3m1 Termination central [] Strength = 240@108: Quake I save: e3m6 Chambers of torment [] Strength = 240@121: Quake I save: dm1 Place of two deaths [] Strength = 240@131: Quake I save: hip1m1 The pumping station [] Strength = 240@138: Quake I save: hip2m2 The black cathedral [] Strength = 240@166: Quake I save: d8 The underwater base [] Strength = 240@10: ACE/gr ascii file [] Strength = 240@11: ACE/gr ascii file [] Strength = 240@701: Lisp Machine bit-array-file [] Strength = 240@566: DR-DOS executable (COM) [application/x-dosexec] Strength = 240@13: PEM EC private key [] Strength = 230@638: SAPCAR archive data [] Strength = 230@408: %s [] Strength = 230@444: Fast Tracker II Instrument [] Strength = 230@93: Quake I save: e1m6 The door to Chthon [] Strength = 230@97: Quake I save: e2m3 The crypt of decay (dopefish lives!) [] Strength = 230@100: Quake I save: e2m5 The wizard's manse [] Strength = 230@104: Quake I save: e3m3 The tomb of terror [] Strength = 230@112: Quake I save: e4m4 The palace of hate [] Strength = 230@122: Quake I save: dm2 Claustrophobopolis [] Strength = 230@123: Quake I save: dm3 The abandoned base [] Strength = 230@14: Grace project file [] Strength = 230@79: Linux/i386 swap file (new style) (compressed hibernate) [] Strength = 230@43: Cyrus skiplist DB [] Strength = 230@44: Cyrus twoskip DB [] Strength = 230@874: Winamp plug in [] Strength = 230@894: PGP sig [] Strength = 230@895: PGP sig [] Strength = 230@896: PGP sig [] Strength = 230@897: PGP sig [] Strength = 230@898: PGP sig [] Strength = 230@902: MS Windows special zipped file [] Strength = 230@28: Perl script text executable [text/x-perl] Strength = 230@6: pkg Datastream (SVR4) [application/x-svr4-package] Strength = 230@47: Amstrad/Spectrum .DSK data [] Strength = 230@49: Amstrad/Spectrum Extended .DSK data [] Strength = 230@296: MS Windows shortcut [] Strength = 230@256: Scribus Document [] Strength = 220@1019: Interplay MVE Movie [] Strength = 220@278: MIPS archive [application/x-archive] Strength = 220@621: EXP1 archive data [] Strength = 220@98: Creative Labs voice data [audio/x-unknown] Strength = 220@452: SHARP Cell-Phone ringing Melody [] Strength = 220@30: Biosig/alpha trace [biosig/alpha] Strength = 220@10: Clojure script text executable [text/x-clojure] Strength = 220@18: Clojure script text executable [text/x-clojure] Strength = 220@6: Alpha archive [] Strength = 220@90: Quake I save: e1m4 The grisly grotto [] Strength = 220@99: Quake I save: e2m4 The ebon fortress [] Strength = 220@106: Quake I save: e3m7 The haunted halls (secret) [] Strength = 220@109: Quake I save: e4m1 The sewage system [] Strength = 220@114: Quake I save: e4m8 The nameless city (secret) [] Strength = 220@135: Quake I save: hip1m4 Research facility [] Strength = 220@51: KiCad Footprint (Legacy) [] Strength = 220@77: Linux/i386 swap file (new style) with SWSUSP1 image [] Strength = 220@1400: Microsoft Word Document [application/msword] Strength = 220@26: Perl script text executable [text/x-perl] Strength = 220@48: Amstrad/Spectrum DU54 .DSK data [] Strength = 220@10: OpenSSH ECDSA public key [] Strength = 220@11: OpenSSH ECDSA public key [] Strength = 220@12: OpenSSH ECDSA public key [] Strength = 220@354: Internet Explorer cache file [] Strength = 220@7: Smith Corona PWP [] Strength = 211@152: Biosig/FIFF [biosig/fiff] Strength = 210@271: Sample Vision file [] Strength = 210@608: XMMS equalizer preset [] Strength = 210@14: Clojure script text executable [text/x-clojure] Strength = 210@75: Bourne-Again shell script executable (binary data) [text/x-shellscript] Strength = 210@474: Neo Geo Pocket [application/x-neo-geo-pocket-rom] Strength = 210@525: X11 Xauthority data [] Strength = 210@526: X11 Xauthority data [] Strength = 210@527: X11 Xauthority data [] Strength = 210@528: X11 Xauthority data [] Strength = 210@529: X11 Xauthority data [] Strength = 210@530: X11 Xauthority data [] Strength = 210@531: X11 Xauthority data [] Strength = 210@532: X11 Xauthority data [] Strength = 210@533: X11 Xauthority data [] Strength = 210@2439: %s [] Strength = 210@91: Quake I save: e1m8 Ziggurat vertigo (secret) [] Strength = 210@95: Quake I save: e2m1 The installation [] Strength = 210@96: Quake I save: e2m2 The ogre citadel [] Strength = 210@132: Quake I save: hip1m2 Storage facility [] Strength = 210@133: Quake I save: hip1m5 Military complex (secret) [] Strength = 210@156: Quake I save: d11 The genetics lab (secret) [] Strength = 210@47: GIMP curve file [] Strength = 210@251: Canon CR2 raw image data [image/x-canon-cr2] Strength = 210@631: iff image data [] Strength = 210@64: CLISP byte-compiled Lisp program (pre 2004-03-27) [] Strength = 210@290: MSX ExecROM patchfile [] Strength = 201@449: PNG image data (CgBI) [image/png] Strength = 201@26: Java HPROF dump, [] Strength = 200@31: Mugician Module sound file [] Strength = 200@1291: BitTorrent file [application/x-bittorrent] Strength = 200@114: Pdmenu configuration file text [] Strength = 200@11: PostScript Type 1 font text [] Strength = 200@13: PostScript Type 1 font program data [] Strength = 200@154: Quake I save: d3b Secret missions [] Strength = 200@159: Quake I save: d2 Takahiro towers [] Strength = 200@181: Quake I save: ddm7 Sandra's ladder [] Strength = 200@441: PNG image data [image/png] Strength = 200@53: Maple something [] Strength = 200@56: Maple something [] Strength = 200@68: MSVC .wsp version 1.0000.0000 [] Strength = 200@45: Sniffer capture file [] Strength = 200@198: Hangul (Korean) Word Processor File 3.0 [] Strength = 191@142: Biosig/Sigma [biosig/sigma] Strength = 191@353: Embedded OpenType (EOT) [] Strength = 191@23: KiCad Symbol Library [] Strength = 191@38: MSVC program database [application/x-ms-pdb] Strength = 191@184: MSX Kanji Font [] Strength = 190@891: VRML 1 file [model/vrml] Strength = 190@170: Fasttracker II module sound data [audio/x-mod] Strength = 190@235: Sidplay info file [] Strength = 190@268: NIST SPHERE file [] Strength = 190@437: RAD Adlib Tracker Module RAD [] Strength = 190@546: BambooTracker module [] Strength = 190@551: BambooTracker instrument [] Strength = 190@130: Biosig/UNIPRO [biosig/unipro] Strength = 190@145: Biosig/File exchange format (FEF) [biosig/fef] Strength = 190@71: Bourne-Again shell script executable (binary data) [text/x-shellscript] Strength = 190@210: Sega Mega CD disc image [application/x-sega-cd-rom] Strength = 190@214: Sega Mega CD disc image [application/x-sega-cd-rom] Strength = 190@219: Sega Mega CD disc image [application/x-sega-cd-rom] Strength = 190@223: Sega Mega CD disc image [application/x-sega-cd-rom] Strength = 190@349: Sega Saturn disc image [application/x-saturn-rom] Strength = 190@354: Sega Saturn disc image [application/x-saturn-rom] Strength = 190@375: Sega Dreamcast disc image [application/x-dc-rom] Strength = 190@380: Sega Dreamcast disc image [application/x-dc-rom] Strength = 190@547: CGNS Advanced Data Format [] Strength = 190@1579: ntfsclone image, [] Strength = 190@2070: Aculab VoIP firmware [] Strength = 190@32: FrameMaker Font file [application/x-mif] Strength = 190@89: Quake I save: e1m3 The necropolis [] Strength = 190@136: Quake I save: hip2m1 Ancient realms [] Strength = 190@147: Quake I save: hipend Armagon's lair [] Strength = 190@161: Quake I save: d4 Into the flood [] Strength = 190@179: Quake I save: ddm5 Slaughterhouse [] Strength = 190@79: mbsystem info cache [] Strength = 190@8: GNOME keyring [] Strength = 190@55: G-IR binary database [] Strength = 190@539: group 3 fax data [] Strength = 190@995: PartImage [] Strength = 190@1214: Garmin Bitmap file [] Strength = 190@8: Karma Data Structure Version [] Strength = 190@360: Xen saved domain [] Strength = 190@366: Xen saved domain [] Strength = 190@7: MacOS Alias file [] Strength = 190@52: Maple something [] Strength = 190@55: Maple something [] Strength = 190@57: Maple something anomalous. [] Strength = 190@7: Digifax-G3-File [] Strength = 190@9: Mozilla XUL fastload data [] Strength = 190@1047: Windows Program Information File [application/x-dosexec] Strength = 190@6: ASCII font metrics [] Strength = 190@118: Canon Bubble Jet BJC formatted data [] Strength = 190@122: Epson Stylus Color 460 data [] Strength = 190@14: Git bundle [] Strength = 190@311: Sony Wave64 RIFF data [] Strength = 190@326: MBWF/RF64 audio [audio/x-wav] Strength = 190@28: CNS ASCII electron density map [] Strength = 190@56: MAR Area Detector Image, [] Strength = 190@352: Network Instruments Observer capture file [] Strength = 190@141: H2 Database file [] Strength = 190@8: BEA TUXEDO DES mask data [] Strength = 190@6: Xerox InterPress data [] Strength = 190@49: XPConnect Typelib [] Strength = 190@197: Libvirt QEMU Suspend Image [] Strength = 190@203: Libvirt QEMU partial Suspend Image [] Strength = 185@112: XML [text/xml] Strength = 181@31: KiCad Symbol Library Documentation [] Strength = 180@32: Sidmon 2.0 Module sound file [] Strength = 180@47: Android Backup [application/x-google-ab] Strength = 180@893: ISO/IEC 14772 VRML 97 file [model/vrml] Strength = 180@294: SGI SoundTrack project file [] Strength = 180@511: Synthesizer Generator or Kimwitu data [] Strength = 180@513: Kimwitu++ data [] Strength = 180@78: Biosig/Embla [biosig/embla] Strength = 180@6: Clojure script text executable [text/x-clojure] Strength = 180@263: XZ compressed data [application/x-xz] Strength = 180@458: Microsoft Access Database [application/x-msaccess] Strength = 180@460: Microsoft Access Database [application/x-msaccess] Strength = 180@103: Quake I save: e3m2 Vaults of Zin [] Strength = 180@113: Quake I save: e4m5 Hell's atrium [] Strength = 180@115: Quake I save: e4m6 The pain maze [] Strength = 180@124: Quake I save: dm4 The bad place [] Strength = 180@126: Quake I save: dm6 The dark zone [] Strength = 180@134: Quake I save: hip1m3 The lost mine [] Strength = 180@139: Quake I save: hip2m3 The catacombs [] Strength = 180@141: Quake I save: hip2m5 Mortum's keep [] Strength = 180@157: Quake I save: d4b Back to Malice [] Strength = 180@163: Quake I save: d6 Nuclear plant [] Strength = 180@167: Quake I save: d9 Takahiro base [] Strength = 180@169: Quake I save: d13 Stayin' alive [] Strength = 180@177: Quake I save: ddm3 Crazy eights! [] Strength = 180@59: Mathematica PBF (fonts I think) [] Strength = 180@7: vCalendar calendar file [text/calendar] Strength = 180@15: MSVC .ide [] Strength = 180@61: GLF_TEXT [] Strength = 180@111: PCP pmieconf rules [] Strength = 180@13: SPECjbb [] Strength = 180@99: SQLite 3.x database [application/x-sqlite3] Strength = 180@4: OpenSSH RSA1 private key, [] Strength = 176@902: X3D (Extensible 3D) model xml text [model/x3d+xml] Strength = 171@233: part of multipart Debian package [application/vnd.debian.binary-package] Strength = 171@164: ultratracker V1.%.1s module sound data [audio/x-mod] Strength = 171@61: KiCad Symbol Library Table [] Strength = 171@8: SVG Scalable Vector Graphics image [image/svg+xml] Strength = 171@26: OpenStreetMap XML data [] Strength = 171@144: Portable Embosser Format [application/x-pef+xml] Strength = 171@288: MS Windows HyperTerminal profile [] Strength = 170@30: Art Of Noise Module sound file [] Strength = 170@888: Vivo video data [] Strength = 170@1058: Material exchange container format [application/mxf] Strength = 170@1237: LBR archive data [] Strength = 170@30: T64 tape Image [] Strength = 170@93: Famicom Disk System disk image: [application/x-fds-disk] Strength = 170@551: Tokyo Cabinet [] Strength = 170@582: TokyoCabinet database [] Strength = 170@86: Quake I save: start Introduction [] Strength = 170@107: Quake I save: e3m5 Wind tunnels [] Strength = 170@146: Quake I save: hip3m4 The gauntlet [] Strength = 170@155: Quake I save: d10 The hospital (secret) [] Strength = 170@160: Quake I save: d3 A rat's life [] Strength = 170@241: Canon CIFF raw image data [image/x-canon-crw] Strength = 170@501: MIFF image data [] Strength = 170@54: Maple something [] Strength = 170@906: Icon for MS Windows [] Strength = 170@7: Qt Resource Collection file [] Strength = 170@72: GEDCOM data [] Strength = 170@73: GEDCOM data [] Strength = 170@17: SE Linux policy module source [] Strength = 170@18: SE Linux policy module source [] Strength = 161@67: KiCad Footprint Library Table [] Strength = 161@69: PJL encapsulated PostScript document text [] Strength = 160@661: ARS-Sfx archive data [] Strength = 160@575: CFF Song [] Strength = 160@663: iMelody Ringtone Format [] Strength = 160@8: BlockHashLoc recovery info, [] Strength = 160@133: Biosig/WCP [biosig/wcp] Strength = 160@11: CCS C64 Emultar Cartridge Image [] Strength = 160@347: Spline Font Database [application/vnd.font-fontforge-sfd] Strength = 160@116: Quake I save: e4m7 Azure agony [] Strength = 160@125: Quake I save: dm5 The cistern [] Strength = 160@140: Quake I save: hip2m4 The crypt [] Strength = 160@142: Quake I save: hip3m1 Tur torment [] Strength = 160@143: Quake I save: hip3m2 Pandemonium [] Strength = 160@151: Quake I save: start The academy [] Strength = 160@165: Quake I save: d7b The foundry [] Strength = 160@170: Quake I save: d14 B.O.S.S. HQ [] Strength = 160@176: Quake I save: ddm2 Sub station [] Strength = 160@164: Gnumeric spreadsheet [] Strength = 160@7: Gnumeric spreadsheet [application/x-gnumeric] Strength = 160@899: PGP sig [] Strength = 160@12: OASIS Stream file [] Strength = 160@29: PostScript document [] Strength = 160@50: HP Printer Job Language data [] Strength = 160@59: HP Printer Job Language data [] Strength = 160@78: HP Printer Job Language data [] Strength = 160@113: PCP pmie config [] Strength = 160@17: SPECweb [] Strength = 160@93: SunPC 4.0 Properties Values [] Strength = 151@374: MS-DOS KEYBoard Layout file [] Strength = 151@387: Windows Registry little-endian text (Win2K or above) [text/x-ms-regedit] Strength = 150@83: TADS [] Strength = 150@919: Video title set, [] Strength = 150@921: Video manager, [] Strength = 150@1346: Personal NetWare Packed File [] Strength = 150@595: VQF data [] Strength = 150@81: Version Biosig/ETG4000 [biosig/etg4000] Strength = 150@47: C64 Raw Tape File (.tap), [] Strength = 150@67: Bourne-Again shell script executable (binary data) [text/x-shellscript] Strength = 150@1171: SYSLINUX loader [] Strength = 150@2281: Marvell Libertas firmware [] Strength = 150@2311: dvdisaster error correction file [] Strength = 150@92: Quake I save: e1m5 Gloom keep [] Strength = 150@98: Quake I save: e2m7 Underearth (secret) [] Strength = 150@130: Quake I save: start Command HQ [] Strength = 150@197: Build engine group file [] Strength = 150@475: GIF image data [image/gif] Strength = 150@515: SunPHIGS [] Strength = 150@1707: Khronos KTX texture [] Strength = 150@12: JPEG image data [image/jpeg] Strength = 150@101: JPEG 2000 [] Strength = 150@65: Cyrus sieve bytecode data, [] Strength = 150@23: Maple help file with extra carriage return at start (yuck) [] Strength = 150@1118: MS Windows HtmlHelp Data [] Strength = 150@28: Microsoft Visual C .pch [] Strength = 150@13: PDF document [application/pdf] Strength = 150@46: PPD file [] Strength = 150@70: GEDCOM data [] Strength = 150@71: GEDCOM data [] Strength = 150@20: SE Linux policy interface source [] Strength = 150@59: Open Inventor 2.0 file [] Strength = 150@67: GLS_TEXT [] Strength = 150@104: PCP pmdahotproc config [] Strength = 150@6: teapot work sheet (XDR format) [] Strength = 150@22: header for PowerPC PEF executable [] Strength = 150@349: MS Windows help cache [] Strength = 150@246: Freemind document [application/x-freemind] Strength = 141@99: TADS 3 game data (format version %d) [] Strength = 141@12: Public Suffix List data (optimized) [] Strength = 140@72: AMOS Basic source code [] Strength = 140@929: MythTV NuppelVideo [] Strength = 140@311: NeXT/Apple typedstream data, big endian [] Strength = 140@316: NeXT/Apple typedstream data, little endian [] Strength = 140@581: PUCrunch archive data [] Strength = 140@1288: BitTorrent file [application/x-bittorrent] Strength = 140@392: OctaMED Soundstudio compressed file [] Strength = 140@943: WOPL instrument [] Strength = 140@945: WOPL instrument bank [] Strength = 140@18: Korn shell script executable (binary data) [text/x-shellscript] Strength = 140@20: Message Sequence Chart (document) [] Strength = 140@576: Quick Database Manager, little endian [] Strength = 140@577: Quick Database Manager, big endian [] Strength = 140@303: ELF [] Strength = 140@1173: SYSLINUX loader [] Strength = 140@14: PostScript Type 1 font program data [] Strength = 140@15: PostScript Type 1 font program data [] Strength = 140@49: Clam AntiVirus [] Strength = 140@113: Avira AntiVir quarantined [application/x-avira-qua] Strength = 140@162: Quake I save: d5 The flood [] Strength = 140@171: Quake I save: d15 Showdown! [] Strength = 140@260: TIFF image data, big-endian [image/tiff] Strength = 140@264: TIFF image data, little-endian [image/tiff] Strength = 140@1257: Radiance HDR image data [] Strength = 140@8: IslandWrite document [] Strength = 140@53: Linux make config build file (old) [] Strength = 140@22: Maple help file [] Strength = 140@32: Mathematica notebook version 2.x [] Strength = 140@36: Mathematica notebook version 2.x [] Strength = 140@12: vCard visiting card [text/vcard] Strength = 140@1021: RabbitGraph file [] Strength = 140@7: PDF document [application/pdf] Strength = 140@21: FDF document [application/vnd.fdf] Strength = 140@6: sc spreadsheet file [application/x-sc] Strength = 140@36: sendmail m4 text file [] Strength = 140@58: IRIS Inventor 1.0 file [] Strength = 140@312: AIX iptrace capture file [] Strength = 140@313: AIX iptrace capture file [] Strength = 140@13: OpenSSH ED25519 public key [] Strength = 140@59: ncurses6 screen image [] Strength = 140@13: Internet Archive File [application/x-ia-arc] Strength = 131@103: TADS 3 saved game data (format version [] Strength = 131@1367: DOS/MBR boot sector [] Strength = 131@1813: reMarkable tablet notebook lines, 1404 x 1872, %x page(s) [] Strength = 131@1820: reMarkable tablet page (v%c), 1404 x 1872, [] Strength = 131@39: KiCad Board Layout [] Strength = 131@97: Protein Data Bank data, ID Code %s [chemical/x-pdb] Strength = 130@90: TADS [] Strength = 130@46: catalog translation [] Strength = 130@413: NuLIB archive data [] Strength = 130@429: DPA archive data [] Strength = 130@639: SAPCAR archive data [] Strength = 130@590: LockStream Embedded file (mostly MP3 on old Nokia phones) [] Strength = 130@37: Biosig/BCI2000 [] Strength = 130@66: Biosig/CED SMR [biosig/ced-smr] Strength = 130@161: MegaCAD 2D/3D drawing [] Strength = 130@9: POSIX shell script executable (binary data) [text/x-shellscript] Strength = 130@363: snappy framed data [application/x-snappy-framed] Strength = 130@2395: disk image data (YAZE) [] Strength = 130@12: FrameMaker document [application/x-mif] Strength = 130@28: Boom or linuxdoom demo [] Strength = 130@92: IVS Fledermaus TDR file [] Strength = 130@190: HP Bitmapfile [] Strength = 130@514: PHIGS clear text archive [] Strength = 130@74: Linux/i386 swap file [] Strength = 130@83: Linux/i386 swap file (new style), [] Strength = 130@96: Linux/ppc swap file [] Strength = 130@107: Linux/ia64 swap file [] Strength = 130@7: Metastore data file, [] Strength = 130@630: COM executable for MS-DOS, Compack compressed [application/x-dosexec] Strength = 130@1019: First Choice database [] Strength = 130@1121: GFA-BASIC 3 data [] Strength = 130@5: Octave binary data (little endian) [] Strength = 130@6: Octave binary data (big endian) [] Strength = 130@58: perl Storable (v0.6) data [] Strength = 130@103: Imagen printer [] Strength = 130@146: HP LaserJet 1000 series downloadable firmware [] Strength = 130@7: project file for ftnchek [] Strength = 130@22: BRIX Electron Density Map [] Strength = 130@27: XPLOR ASCII Electron Density Map [] Strength = 130@39: R-Axis Area Detector Image: [] Strength = 130@47: R-Axis Area Detector Image, Win32: [] Strength = 130@20: openssl enc'd data with salted password, base64 encoded [] Strength = 130@17: VICAR label file [] Strength = 130@737: PaintShop Pro color palette [] Strength = 125@115: Linux kernel [] Strength = 121@55: Apple DOS 3.3 Image [] Strength = 121@74: Apple Pascal Image [] Strength = 120@69: TADS [] Strength = 120@75: TADS [] Strength = 120@49: AmigaGuide file [] Strength = 120@476: Apple Desktop Services Store [] Strength = 120@1275: GTKtalog catalog data, [] Strength = 120@439: XMS Adlib Module [] Strength = 120@516: TFMX module sound data [] Strength = 120@577: A2M Song [] Strength = 120@191: lzop compressed data [] Strength = 120@14: Vim encrypted file data [] Strength = 120@214: Smart Boot Manager backup file [] Strength = 120@244: Norton Utilities disc image data [] Strength = 120@1832: DOS floppy 360k [] Strength = 120@1834: DOS floppy 720k [] Strength = 120@1836: DOS floppy 1440k [] Strength = 120@1839: DOS floppy 720k, IBM [] Strength = 120@1841: DOS floppy 1440k, mkdosfs [] Strength = 120@1844: Atari-ST floppy 360k [] Strength = 120@1845: Atari-ST floppy 720k [] Strength = 120@2051: ReiserFS V3.6 [] Strength = 120@2052: ReiserFS V3.6.19 [] Strength = 120@2213: Delta ISO data [] Strength = 120@2230: Oracle Clustered Filesystem, [] Strength = 120@2244: Oracle Clustered Filesystem, [] Strength = 120@2265: Files-11 On-Disk Structure [] Strength = 120@59: Macromedia Freehand 7 Document [] Strength = 120@60: Macromedia Freehand 8 Document [] Strength = 120@62: Macromedia Freehand 9 Document [] Strength = 120@37: FrameMaker Book file [application/x-mif] Strength = 120@152: Quake I save: d1 The lab [] Strength = 120@153: Quake I save: d1b Area 33 [] Strength = 120@691: FITS image data [image/fits] Strength = 120@21: Maple help file [] Strength = 120@34: Maple worksheet [] Strength = 120@30: Mathematica notebook version 2.x [] Strength = 120@40: Mathematica notebook version 2.x [] Strength = 120@42: Mathematica notebook version 2.x [] Strength = 120@655: Microsoft Word document data [application/msword] Strength = 120@861: Lotus WordPro [application/vnd.lotus-wordpro] Strength = 120@1017: First Choice document [] Strength = 120@1024: MKS Spell hash list [] Strength = 120@11: Microsoft Visual C .APS file [] Strength = 120@18: MSVC .res [] Strength = 120@19: MSVC .res [] Strength = 120@20: MSVC .res [] Strength = 120@7: ASCII font bits [] Strength = 120@101: PCP pmlogger config [] Strength = 120@10: Compiled SGML rules file [] Strength = 120@12: A/E SGML Document binary [] Strength = 120@14: A/E SGML binary styles file [] Strength = 120@11: Spectrum +3 data [] Strength = 116@200: , rawbits, bitmap [image/x-portable-bitmap] Strength = 116@207: , rawbits, greymap [image/x-portable-greymap] Strength = 116@214: , rawbits, pixmap [image/x-portable-pixmap] Strength = 115@266: DOS/MBR boot sector [] Strength = 115@1998: [] Strength = 111@60: Digital Symphony sequence (RISC OS), [] Strength = 111@1026: Windows Television DVR Media [] Strength = 111@29: APT cache data, version %u [] Strength = 111@34: APT cache data, version %u [] Strength = 111@328: [] Strength = 111@330: [] Strength = 111@332: [] Strength = 111@765: Nintendo GameCube disc image (WDFv1 format): [application/x-gamecube-rom] Strength = 111@1161: isolinux Loader [] Strength = 111@1215: NetBSD mbr [] Strength = 111@1250: AdvanceMAME mbr [] Strength = 111@1259: Turton mbr ( [] Strength = 111@10: EDID data, version %u. [] Strength = 111@48: [] Strength = 111@1049: DjVu multiple page document [image/vnd.djvu] Strength = 111@15: KiCad Schematic Document [] Strength = 111@385: Journal file [application/octet-stream] Strength = 111@398: BCache [] Strength = 111@379: [] Strength = 111@449: [] Strength = 111@452: [] Strength = 111@454: [] Strength = 111@456: [] Strength = 111@459: [] Strength = 111@461: [] Strength = 111@1499: DOS 3.3 backup control file, sequence %d [] Strength = 111@19: Qt Translation file [] Strength = 111@84: Microsoft Disk Image eXtended [] Strength = 111@800: [] Strength = 111@803: [] Strength = 110@32: RISC OS music file [] Strength = 110@39: Digital Symphony sound sample (RISC OS), [] Strength = 110@50: Digital Symphony song (RISC OS), [] Strength = 110@6: AMANDA [] Strength = 110@33: Synthesis Module sound file [] Strength = 110@75: AMOS Basic source code [] Strength = 110@21: Android bootimg [] Strength = 110@1014: ARMovie [] Strength = 110@108: Newton package, NOS 1.x, [] Strength = 110@116: Newton package, NOS 2.x, [] Strength = 110@124: Newton package, [] Strength = 110@282: Apple binary property list [] Strength = 110@523: MacPaint image data [] Strength = 110@7: Pebble application [] Strength = 110@152: GNU tar incremental snapshot data [] Strength = 110@297: current ar archive [application/x-archive] Strength = 110@320: thin archive with [] Strength = 110@359: RISC OS archive (ArcFS format) [] Strength = 110@360: RISC OS archive (ArcFS format) [] Strength = 110@573: TSComp archive data [] Strength = 110@710: WinImage archive data [] Strength = 110@787: PAQ archive data [] Strength = 110@1046: RAR archive data, v5 [application/x-rar] Strength = 110@1064: Zip multi-volume archive data, at least PKZIP v2.50 to extract [application/zip] Strength = 110@1303: Zip archive data [application/zip] Strength = 110@1366: Foxit add-on/update [application/x-fzip] Strength = 110@1394: KGB Archiver file [] Strength = 110@1486: BBeB ebook data, unencrypted [] Strength = 110@1546: Acronis True Image backup [application/x-acronis-tib] Strength = 110@175: Screamtracker 2 module sound data [audio/x-mod] Strength = 110@178: Screamtracker 2 module sound data [audio/x-mod] Strength = 110@406: Oktalyzer module data [] Strength = 110@443: Open Cubic Player Module Inforation MDZ [] Strength = 110@556: RdosPlay RAW [] Strength = 110@562: MPU-401 Trakker [] Strength = 110@581: Spectrum 128 tune [] Strength = 110@859: Garmin Voice Processing Module (encrypted) [audio/x-vpm-garmin] Strength = 110@895: AProSys module [] Strength = 110@918: Klystrack song [] Strength = 110@938: Klystrack instrument [] Strength = 110@951: DMX OP2 instrument data [] Strength = 110@38: Biosig/BCI2000 [biosig/bci2000] Strength = 110@42: Biosig/Biosemi data format [biosig/bdf] Strength = 110@54: Biosig/EDF: European Data format [biosig/edf] Strength = 110@61: Biosig/Heka Patchmaster [] Strength = 110@62: Biosig/Heka Patchmaster [] Strength = 110@63: Biosig/Heka Patchmaster [biosig/heka] Strength = 110@69: Biosig/CFWB [biosig/cfwb] Strength = 110@75: Biosig/EBS [biosig/ebs] Strength = 110@91: Biosig/ISHNE [biosig/ishne] Strength = 110@95: Biosig/MFER [] Strength = 110@99: Biosig/NEV [] Strength = 110@113: Biosig/SCP-ECG format CEN 1064:2005/ISO 11073:91064 [biosig/scpecg] Strength = 110@3: BLCR [] Strength = 110@14: BLCR [] Strength = 110@7: BTSnoop [] Strength = 110@14: GCR Image [] Strength = 110@23: PC64 Freezer Image [] Strength = 110@167: OpenHSF (Hoops Stream Format) [] Strength = 110@27: Claris works dictionary [] Strength = 110@367: qpress compressed data [application/x-qpress] Strength = 110@382: UCL compressed data [] Strength = 110@118: Game Boy ROM image [application/x-gameboy-rom] Strength = 110@396: Nintendo 64 ROM image [application/x-n64-rom] Strength = 110@406: Nintendo 64 ROM image (V64) [application/x-n64-rom] Strength = 110@413: Nintendo 64 ROM image (wordswapped) [application/x-n64-rom] Strength = 110@420: Nintendo 64 ROM image (32-bit byteswapped) [application/x-n64-rom] Strength = 110@430: Game Boy Advance ROM image [application/x-gba-rom] Strength = 110@443: Nintendo DS ROM image [application/x-nintendo-ds-rom] Strength = 110@464: Nintendo DS Slot-2 ROM image (PassMe) [application/x-nintendo-ds-rom] Strength = 110@488: Sony Playstation executable [] Strength = 110@71: LLVM raw profile data, [] Strength = 110@75: LLVM raw profile data, [] Strength = 110@85: LLVM indexed profile data, [] Strength = 110@89: LLVM indexed profile data, [] Strength = 110@510: TDB database [] Strength = 110@597: Hopper database [] Strength = 110@19: bsdiff(1) patch file [] Strength = 110@52: profiling data file [] Strength = 110@6: Extended display identification data dump [application/x-edid-dump] Strength = 110@21: Erlang DETS file [] Strength = 110@249: Norton Disk Doctor UnDo file [] Strength = 110@1143: romfs filesystem, version 1 [] Strength = 110@1703: HAMMER filesystem (little-endian), [] Strength = 110@2050: ReiserFS V3.5 [] Strength = 110@2066: EST flat binary [] Strength = 110@2238: Oracle ASM Volume, [] Strength = 110@2240: Oracle ASM Volume (cleared), [] Strength = 110@2251: Oracle ASM Volume, [] Strength = 110@2253: Oracle ASM Volume (cleared), [] Strength = 110@2258: Compaq/HP RILOE floppy image [] Strength = 110@2276: PowerISO Direct-Access-Archive [] Strength = 110@2294: BTRFS Filesystem [] Strength = 110@2399: ReFS filesystem image [] Strength = 110@2404: EWF/Expert Witness/EnCase image file format [] Strength = 110@21: FrameMaker MIF (ASCII) file [application/x-mif] Strength = 110@140: scrshot(1) screenshot, [] Strength = 110@158: Quake I save: d1c Area 44 [] Strength = 110@180: Quake I save: ddm6 Domino [] Strength = 110@184: MAME CHD compressed hard disk image, [] Strength = 110@63: SeaBeam 2100 DR multibeam sonar [] Strength = 110@64: SeaBeam 2100 PR multibeam sonar [] Strength = 110@18: GIMP XCF image data, [image/x-xcf] Strength = 110@30: GNOME Catalogue (gtktalog) [] Strength = 110@46: GVariant Database file, [] Strength = 110@236: GPT data structure (nonstandard: at LBA 0) [] Strength = 110@24: Vulkan trace file, little-endian [] Strength = 110@27: Vulkan trace file, big-endian [] Strength = 110@8: Guile Object [] Strength = 110@197: HP NLS message catalog, [] Strength = 110@16: AIX message catalog [] Strength = 110@534: FBM image data [] Strength = 110@739: PDS (JPL) image data [] Strength = 110@744: PDS (VICAR) image data [] Strength = 110@924: SMJPEG [] Strength = 110@970: Webshots Desktop .wbz file [] Strength = 110@974: Hercules CKD DASD image file [] Strength = 110@979: Hercules compressed CKD DASD image file [] Strength = 110@984: Hercules CKD DASD shadow file [] Strength = 110@1132: Hierarchical Data Format (version 5) data [application/x-hdf] Strength = 110@1134: Hierarchical Data Format (version 5) with 512 bytes user block [application/x-hdf] Strength = 110@1136: Hierarchical Data Format (version 5) with 1k user block [application/x-hdf] Strength = 110@1138: Hierarchical Data Format (version 5) with 2k user block [application/x-hdf] Strength = 110@1140: Hierarchical Data Format (version 5) with 4k user block [application/x-hdf] Strength = 110@1252: AVCHD Clip Information [] Strength = 110@1293: JPEG-XR Image [] Strength = 110@1402: farbfeld image data, [] Strength = 110@1512: Microsoft DirectDraw Surface (DDS): [] Strength = 110@9: IslandDraw document [] Strength = 110@158: Linux [] Strength = 110@283: LVM2 PV (Linux Logical Volume Manager) [] Strength = 110@297: LVM2 PV (Linux Logical Volume Manager) [] Strength = 110@309: LVM2 PV (Linux Logical Volume Manager) [] Strength = 110@321: LVM2 PV (Linux Logical Volume Manager) [] Strength = 110@468: mlocate database [] Strength = 110@458: Mac OS X bill of materials (BOM) file [] Strength = 110@10: Mathematica version 2 notebook [] Strength = 110@12: Mathematica version 2 notebook [] Strength = 110@38: Mathematica notebook version 2.x [] Strength = 110@44: Mathematica notebook version 2.x [] Strength = 110@18: Mozilla lz4 compressed data [application/x-lz4+json] Strength = 110@704: Microsoft Excel Worksheet [application/vnd.ms-excel] Strength = 110@859: Lotus WordPro [application/vnd.lotus-wordpro] Strength = 110@888: tz3 ms-works file [] Strength = 110@889: tz3 ms-works file [] Strength = 110@890: tz3 ms-works file [] Strength = 110@1018: First Choice database [] Strength = 110@1023: MKS Spell hash list (old format) [] Strength = 110@1115: MS Advisor help file [] Strength = 110@1130: Microsoft Cabinet archive data [] Strength = 110@1373: Microsoft WinCE install header [] Strength = 110@1422: Microsoft Reader eBook Data [] Strength = 110@281: MSX cassette archive [] Strength = 110@21: Net2phone [] Strength = 110@25: AOL ART image [] Strength = 110@26: AOL ART image [] Strength = 110@5: OCaml [] Strength = 110@8: OLE 2 Compound Document [] Strength = 110@49: OS/2 INI [] Strength = 110@52: iSiloX E-book [] Strength = 110@57: Mobipocket E-book [] Strength = 110@73: AportisDoc/PalmDOC E-book [] Strength = 110@80: BDicty PalmOS document [] Strength = 110@82: DB PalmOS document [] Strength = 110@84: FireViewer/ImageViewer PalmOS document [] Strength = 110@86: HanDBase PalmOS document [] Strength = 110@88: InfoView PalmOS document [] Strength = 110@90: iSilo PalmOS document [] Strength = 110@92: JFile PalmOS document [] Strength = 110@94: JFile Pro PalmOS document [] Strength = 110@96: List PalmOS document [] Strength = 110@98: MobileDB PalmOS document [] Strength = 110@100: PeanutPress PalmOS document [] Strength = 110@102: Plucker PalmOS document [] Strength = 110@104: QuickSheet PalmOS document [] Strength = 110@106: SuperMemo PalmOS document [] Strength = 110@108: TealDoc PalmOS document [] Strength = 110@110: TealInfo PalmOS document [] Strength = 110@112: TealMeal PalmOS document [] Strength = 110@114: TealPaint PalmOS document [] Strength = 110@116: ThinkDB PalmOS document [] Strength = 110@118: Tides PalmOS document [] Strength = 110@120: TomeRaider PalmOS document [] Strength = 110@154: Mobipocket E-book [] Strength = 110@8: Parrot bytecode [] Strength = 110@26: Maki-chan v2 image, [] Strength = 110@77: Hash::SharedMem master file, big-endian [] Strength = 110@83: Hash::SharedMem master file, little-endian [] Strength = 110@89: Hash::SharedMem data file, big-endian [] Strength = 110@95: Hash::SharedMem data file, little-endian [] Strength = 110@19: Poly/ML saved state [] Strength = 110@22: Poly/ML saved module [] Strength = 110@7: rpmsg Restricted Permission Message [] Strength = 110@12: Plot84 plotting file [] Strength = 110@46: IRIX vmcore dump of [] Strength = 110@50: SGI Audit file [] Strength = 110@54: Wingz compiled script [] Strength = 110@55: Wingz spreadsheet [] Strength = 110@56: Wingz help file [] Strength = 110@89: PCP [] Strength = 110@92: PCP pmchart view [] Strength = 110@95: PCP kmchart view [] Strength = 110@133: Alias Maya Binary File, [] Strength = 110@135: Alias Maya Binary File, [] Strength = 110@25: QL firmware executable (BCPL) [] Strength = 110@329: RADCOM WAN/LAN Analyzer capture file [] Strength = 110@37: Spectrum .TZX data [] Strength = 110@50: Spectrum .SCL Betadisk image [] Strength = 110@129: SQLite Rollback Journal [] Strength = 110@8: OpenSSH DSA public key [] Strength = 110@9: OpenSSH RSA public key [] Strength = 110@18: openssl enc'd data with salted password [] Strength = 110@13: TI-80 Graphing Calculator File. [] Strength = 110@14: TI-81 Graphing Calculator File. [] Strength = 110@18: TI-73 Graphing Calculator [] Strength = 110@36: TI-82 Graphing Calculator [] Strength = 110@53: TI-83 Graphing Calculator [] Strength = 110@71: TI-83+ Graphing Calculator [] Strength = 110@92: TI-85 Graphing Calculator [] Strength = 110@125: TI-86 Graphing Calculator [] Strength = 110@156: TI-89 Graphing Calculator [] Strength = 110@174: TI-92 Graphing Calculator [] Strength = 110@191: TI-92+/V200 Graphing Calculator [] Strength = 110@209: TI-XX Graphing Calculator (FLASH) [] Strength = 110@210: TI-XX Graphing Calculator (FLASH) [] Strength = 110@9: VICAR image data [] Strength = 110@12: Microsoft Disk Image, Virtual Server or Virtual PC [application/x-virtualbox-vhd] Strength = 110@51: MS Windows Vista Event Log [] Strength = 110@200: Hangul (Korean) Word Processor File 2000 [application/x-hwp] Strength = 110@6: XDelta binary patch file 0.14 [] Strength = 110@7: XDelta binary patch file 0.18 [] Strength = 110@8: XDelta binary patch file 0.20 [] Strength = 110@9: XDelta binary patch file 1.0 [] Strength = 110@10: XDelta binary patch file 1.0.4 [] Strength = 110@11: XDelta binary patch file 1.1 [] Strength = 110@16: xfsdump archive [] Strength = 110@39: ZFS shapshot (big-endian machine), [] Strength = 110@69: ZFS shapshot (little-endian machine), [] Strength = 106@260: DOS/MBR boot sector [] Strength = 105@21: Common Trace Format (CTF) plain text metadata [] Strength = 101@965: CRI ADX ADPCM audio [audio/x-adx] Strength = 101@235: DOS Emulator image [] Strength = 101@47: KiCad Footprint [] Strength = 101@56: KiCad Netlist [] Strength = 101@190: Garmin map, [] Strength = 101@375: Windows Registry text [text/x-ms-regedit] Strength = 100@487: AppleScript compiled [] Strength = 100@396: JRC archive data [] Strength = 100@421: CrossePAC archive data [] Strength = 100@629: Par archive data [] Strength = 100@712: Compressia archive data [] Strength = 100@841: JAM archive, [] Strength = 100@1034: RAR archive data [application/x-rar] Strength = 100@1309: ACE archive data [] Strength = 100@121: RealMedia file [application/vnd.rn-realmedia] Strength = 100@424: Velvet Studio AMS Module v2.2 [] Strength = 100@425: Extreme Tracker AMS Module v1.3 [] Strength = 100@448: NOA Nancy Codec Movie file [] Strength = 100@8: BBx [] Strength = 100@7: Beetle VM object file [] Strength = 100@50: Biosig/CFS: Cambridge Electronic devices File format [biosig/ced] Strength = 100@10: Blender3D, [] Strength = 100@10: b.out archive [] Strength = 100@21: PC64 Emulator file [] Strength = 100@584: 3DO "Opera" file system [] Strength = 100@618: askSam DB [] Strength = 100@8: Old Erlang BEAM file [] Strength = 100@129: DOSFONT2 encrypted font data [] Strength = 100@31: Linuxdoom save [] Strength = 100@144: Quake I save: hip3m3 Limbo [] Strength = 100@58: GeoSwatch auf text file [] Strength = 100@105: elog journal entry [] Strength = 100@168: GNU findutils locate database data [] Strength = 100@192: CIS compimg HP Bitmapfile [] Strength = 100@18: archive [] Strength = 100@19: archive (big format) [] Strength = 100@680: Kodak Photo CD image pack file [] Strength = 100@685: Kodak Photo CD overview pack file [] Strength = 100@741: PDS (CCSD) image data [] Strength = 100@24: StuffIt Archive [application/x-stuffit] Strength = 100@10: MapleVr4 library [] Strength = 100@11: Mozilla lz4 compressed bookmark data [] Strength = 100@993: Borland font [] Strength = 100@999: Borland device [] Strength = 100@1039: MegaDots [] Strength = 100@1428: Windows Embedded CE binary image [] Strength = 100@1439: Mallard BASIC Jetsam index data [] Strength = 100@8: Bagpipe [] Strength = 100@6: NASA SPICE file (binary format) [] Strength = 100@19: NEWEZD Electron Density Map [] Strength = 100@12: kbd map file [] Strength = 100@18: SHARC architecture file [] Strength = 100@19: SHARC architecture file [] Strength = 100@7: GNU SmallTalk [] Strength = 100@53: Spectrum .HDF hard disk image [] Strength = 91@290: CoreFoundation binary property list data, version 0x%c [] Strength = 91@813: Garmin Voice Processing Module [audio/x-vpm-wav-garmin] Strength = 91@46: https://datadryad.org/profile/v3.1 [text/xml] Strength = 91@2221: OpenVMS backup saveset data [] Strength = 91@877: [] Strength = 91@870: InstallShield Uninstall Script [] Strength = 91@215: MSX device BIOS [] Strength = 91@245: [] Strength = 90@937: MythTV NuppelVideo [] Strength = 90@9: NuFile archive (apple ][) data [] Strength = 90@10: NuFile archive (apple ][) data [] Strength = 90@7: Applixware [] Strength = 90@170: ASCII cpio archive (pre-SVR4 or odc) [] Strength = 90@171: ASCII cpio archive (SVR4 with no CRC) [] Strength = 90@172: ASCII cpio archive (SVR4 with CRC) [] Strength = 90@385: BSArc/BS2 archive data [] Strength = 90@415: PAKLeo archive data [] Strength = 90@425: KBoom archive data [] Strength = 90@453: FoxSQZ archive data [] Strength = 90@577: Squash archive data [] Strength = 90@625: NRV archive data [] Strength = 90@682: TPac archive data [] Strength = 90@1213: StarView MetaFile [] Strength = 90@366: Yamaha TX Wave [] Strength = 90@569: eXtra Simple Music [] Strength = 90@614: LICQ configuration file [] Strength = 90@955: AdLib instrument data [] Strength = 90@16: Biosig/Axon Binary format [biosig/abf2] Strength = 90@96: Biosig/MFER [biosig/mfer] Strength = 90@100: Biosig/NEV [biosig/nev] Strength = 90@107: Biosig/Plexon v2.0 [biosig/plexon] Strength = 90@116: Biosig/SIGIF [biosig/sigif] Strength = 90@99: cscope reference data [] Strength = 90@26: Power 64 C64 Emulator Snapshot [] Strength = 90@54: DWG AutoDesk AutoCAD Release 1.40 [image/vnd.dwg] Strength = 90@56: DWG AutoDesk AutoCAD Release 2.05 [image/vnd.dwg] Strength = 90@58: DWG AutoDesk AutoCAD Release 2.10 [image/vnd.dwg] Strength = 90@60: DWG AutoDesk AutoCAD Release 2.21 [image/vnd.dwg] Strength = 90@62: DWG AutoDesk AutoCAD Release 2.22 [image/vnd.dwg] Strength = 90@64: DWG AutoDesk AutoCAD Release 2.22 [image/vnd.dwg] Strength = 90@66: DWG AutoDesk AutoCAD Release 2.50 [image/vnd.dwg] Strength = 90@68: DWG AutoDesk AutoCAD Release 2.60 [image/vnd.dwg] Strength = 90@70: DWG AutoDesk AutoCAD Release 9 [image/vnd.dwg] Strength = 90@72: DWG AutoDesk AutoCAD Release 10 [image/vnd.dwg] Strength = 90@74: DWG AutoDesk AutoCAD Release 11/12 [image/vnd.dwg] Strength = 90@81: DWG AutoDesk AutoCAD Release 13 [image/vnd.dwg] Strength = 90@83: DWG AutoDesk AutoCAD Release 14 [image/vnd.dwg] Strength = 90@85: DWG AutoDesk AutoCAD 2000/2002 [image/vnd.dwg] Strength = 90@93: DWG AutoDesk AutoCAD 2004/2005/2006 [image/vnd.dwg] Strength = 90@95: DWG AutoDesk AutoCAD 2007/2008/2009 [image/vnd.dwg] Strength = 90@97: DWG AutoDesk AutoCAD 2010/2011/2012 [image/vnd.dwg] Strength = 90@99: DWG AutoDesk AutoCAD 2013/2014 [image/vnd.dwg] Strength = 90@9: Chord text file [] Strength = 90@14: Power-Tab v3 Tablature File [] Strength = 90@15: Power-Tab v4 Tablature File [] Strength = 90@7: Citrus locale declaration for LC_CTYPE [] Strength = 90@24: Claris Works palette files .plt [] Strength = 90@9: TTCN Abstract Test Suite [] Strength = 90@22: Message Sequence Chart (subchart) [] Strength = 90@246: 7-zip archive data, [] Strength = 90@623: MUIbase DB [] Strength = 90@628: NetBSD Constant Database [] Strength = 90@28: Vim swap file [] Strength = 90@35: Nano swap file [] Strength = 90@6: Flow Cytometry Standard (FCS) data, version 1.0 [] Strength = 90@7: Flow Cytometry Standard (FCS) data, version 2.0 [] Strength = 90@8: Flow Cytometry Standard (FCS) data, version 3.0 [] Strength = 90@2321: CROMFS [] Strength = 90@62: SeaBeam 2100 multibeam sonar [] Strength = 90@130: Point Cloud Data [] Strength = 90@459: ZIF image (GIF+deflate alpha) [image/x-unknown] Strength = 90@464: FGF image (GIF+deflate beta) [image/x-unknown] Strength = 90@740: PDS (JPL) image data [] Strength = 90@742: PDS (CCSD) image data [] Strength = 90@846: XV thumbnail image data [] Strength = 90@954: XV "thumbnail file" (icon) data [] Strength = 90@1147: Xara graphics file [] Strength = 90@66: Linux/i386 PC Screen Font v2 data, [] Strength = 90@350: LUKS encrypted file, [] Strength = 90@8: LUKS encrypted file, [] Strength = 90@25: Maple help file, old style [] Strength = 90@29: Maple worksheet [] Strength = 90@8: Mathcad document [] Strength = 90@76: Matlab v5 mat-file [] Strength = 90@678: Microsoft Word 2.0 Document [application/msword] Strength = 90@1020: First Choice device file [] Strength = 90@1438: Mallard BASIC Jetsam data [] Strength = 90@6: NumPy array, [] Strength = 90@43: OS/2 INF [] Strength = 90@45: OS/2 HLP [] Strength = 90@9: Maki-chan v1. [] Strength = 90@150: Epson ESC/Page language printer data [] Strength = 90@12: Qt Binary Resource file [] Strength = 90@98: PCP pmview config [] Strength = 90@36: SoftQuad troff Context intermediate for IMAGEN imPRESS [] Strength = 90@80: iRiver Database file [] Strength = 90@8: SymbOS executable [] Strength = 90@14: SymbOS DOX document [] Strength = 90@33: SymbOS video [] Strength = 90@6: Tgif file version [] Strength = 90@25: AVR assembler object code [] Strength = 90@214: Intel Quark Express Document (English) [] Strength = 90@215: Intel Quark Express Document (Korean) [] Strength = 90@216: Motorola Quark Express Document (English) [application/x-quark-xpress-3] Strength = 90@218: Motorola Quark Express Document (Korean) [] Strength = 90@11: ZyXEL voice data [] Strength = 81@81: PackDir archive (RISC OS) [] Strength = 81@941: [] Strength = 81@945: [] Strength = 81@948: [] Strength = 81@950: [] Strength = 81@952: [] Strength = 81@954: [] Strength = 81@956: [] Strength = 81@958: [] Strength = 81@962: [] Strength = 81@967: [] Strength = 81@970: [] Strength = 81@973: [] Strength = 81@976: [] Strength = 81@979: [] Strength = 81@982: [] Strength = 81@987: [] Strength = 81@990: [] Strength = 81@992: [] Strength = 81@994: [] Strength = 81@996: [] Strength = 81@998: [] Strength = 81@1000: [] Strength = 81@1002: [] Strength = 81@1245: [] Strength = 81@1248: [] Strength = 81@1251: [] Strength = 81@15: Claris clip art [] Strength = 81@17: Claris clip art [] Strength = 81@103: Smarty compiled template [] Strength = 81@313: core file [] Strength = 81@354: core file [] Strength = 81@376: core file [] Strength = 81@398: core file [] Strength = 81@874: [] Strength = 81@880: [] Strength = 81@9: RINEX Data, GEO SBAS Broadcast [] Strength = 81@44: Microsoft OOXML [] Strength = 81@247: [] Strength = 81@249: [] Strength = 80@23: RISC OS outline font data, [] Strength = 80@25: RISC OS 1bpp font data, [] Strength = 80@27: RISC OS 4bpp font data [] Strength = 80@35: JamCracker Module sound file [] Strength = 80@36: Hippel-COSO Module sound file [] Strength = 80@47: Amiga E module [] Strength = 80@48: ECX module [] Strength = 80@909: %s [] Strength = 80@41: Apple ProDOS Image [] Strength = 80@369: Crush archive data [] Strength = 80@371: Squeeze It archive data [] Strength = 80@373: SQWEZ archive data [] Strength = 80@423: Freeze archive data [] Strength = 80@445: ZPack archive data [] Strength = 80@598: RAX archive data [] Strength = 80@600: Xtreme archive data [] Strength = 80@602: Pack Magic archive data [] Strength = 80@655: ChiefLZA archive data [] Strength = 80@657: Blink archive data [] Strength = 80@663: AKT32 archive data [] Strength = 80@666: NPack archive data [] Strength = 80@684: Ai archive data [] Strength = 80@685: Ai archive data [] Strength = 80@784: ZZip archive data [] Strength = 80@792: JAR (ARJ Software, Inc.) archive data [] Strength = 80@793: JAR (ARJ Software, Inc.) archive data [] Strength = 80@1008: Swag archive data [] Strength = 80@1252: PMarc SFX archive (CP/M, DOS) [] Strength = 80@1255: PopCom compressed executable (CP/M) [] Strength = 80@1340: sfArk compressed Soundfont [] Strength = 80@40: 3b2 core file [] Strength = 80@135: ULT(imate) Module sound data [] Strength = 80@306: NES Sound File [] Strength = 80@583: BONK, [] Strength = 80@675: Adaptive Multi-Rate Codec (GSM telephony) [audio/amr] Strength = 80@1011: Atari 8-bit SAP audio file [audio/x-sap] Strength = 80@89: Binary Call Format (BCF) version 2.1 [] Strength = 80@102: Binary Call Format (BCF) version 2.2 [] Strength = 80@39: Blender3D BPython script [] Strength = 80@19: LHA archive (c64) [] Strength = 80@48: DWG AutoDesk AutoCAD Release 1.0 [image/vnd.dwg] Strength = 80@50: DWG AutoDesk AutoCAD Release 1.2 [image/vnd.dwg] Strength = 80@52: DWG AutoDesk AutoCAD Release 1.3 [image/vnd.dwg] Strength = 80@107: PHP script Zend Optimizer data [] Strength = 80@333: AFX compressed file data [] Strength = 80@602: IPS patch file [] Strength = 80@605: Playstation Patch File version 3.0 [] Strength = 80@617: Playstation Patch File version 2.0 [] Strength = 80@623: Playstation Patch File version 1.0 [] Strength = 80@935: Vectrex ROM image [] Strength = 80@8: Map file for the Blood Frontier/Red Eclipse FPS games [] Strength = 80@124: ROOT file [] Strength = 80@537: PostgreSQL custom database dump [] Strength = 80@638: Redis RDB file, [] Strength = 80@34: Alpha COFF format core dump (Digital UNIX) [] Strength = 80@36: Alpha COFF format core dump (Digital UNIX) [] Strength = 80@1985: ISO 9660 CD-ROM filesystem data (raw 2352 byte sectors) [application/x-iso9660-image] Strength = 80@1987: High Sierra CD-ROM filesystem data [] Strength = 80@2005: Nero CD image at 0x4B000 [application/x-nrg] Strength = 80@2199: AFS Dump [] Strength = 80@108: X11 Speedo font data [] Strength = 80@71: SAIC generic sensor format (GSF) sonar data, [] Strength = 80@76: MGD77 Header, Marine Geophysical Data Exchange Format [] Strength = 80@233: HP text [] Strength = 80@525: clear text Computer Graphics Metafile [] Strength = 80@1176: Wavelet Scalar Quantization image data [] Strength = 80@1232: Ulead Photo Explorer5 [] Strength = 80@1265: PFS HDR image data [] Strength = 80@7: Interleaf document text [] Strength = 80@489: Kdump compressed dump [] Strength = 80@9: LLVM byte-codes, null compression [] Strength = 80@10: LLVM byte-codes, gzip compression [] Strength = 80@11: LLVM byte-codes, bzip2 compression [] Strength = 80@40: MBX mail folder [] Strength = 80@67: portable voice format [] Strength = 80@73: portable voice format [] Strength = 80@661: Microsoft Word 6.0 Document [application/msword] Strength = 80@699: Microsoft Excel 5.0 Worksheet [application/vnd.ms-excel] Strength = 80@702: Microsoft Excel 5.0 Worksheet [application/vnd.ms-excel] Strength = 80@61: MSVC .sbr [] Strength = 80@17: MSX Gigamix MGSDRV2 music file [] Strength = 80@17: Netscape folder cache [] Strength = 80@56: XLD4(Q4) picture [] Strength = 80@142: SunClock's Vector Map Format data [] Strength = 80@8: Rich Text Format data, [text/rtf] Strength = 80@20: Old EZD Electron Density Map [] Strength = 80@32: Sereal data packet, UTF-8 encoded [application/sereal] Strength = 80@324: HP/UX nettl capture file [] Strength = 80@34: SoftQuad troff Context intermediate for AT&T 495 laser printer [] Strength = 80@133: Panasonic channel list DataBase [] Strength = 80@99: Snoop capture file [] Strength = 80@235: TiEmu skin [] Strength = 80@6: WARC Archive [] Strength = 80@363: MS Windows 3.1 registry file [] Strength = 80@209: ChiWriter file [] Strength = 80@17: o65 [] Strength = 73@1195: SYSLINUX MBR [] Strength = 72@1087: KOffice (>=1.2) [] Strength = 71@116: Adrift game file version [] Strength = 71@12: Dalvik dex file [] Strength = 71@15: Dalvik dex file (optimized for host) [] Strength = 71@103: Partition Information Table for Samsung smartphone [] Strength = 71@229: JVT NAL sequence, H.264 video [] Strength = 71@235: MPEG sequence [video/mpeg] Strength = 71@857: MPEG transport stream data [video/MP2T] Strength = 71@1065: LucasArts Smush Animation Format (SAN) video [] Strength = 71@1067: LucasArts Smush v2 (SANM) video [] Strength = 71@1074: Scaleform video [] Strength = 71@22: Apple ][ WOZ 1.0 Disk Image [] Strength = 71@30: Apple ][ WOZ 2.0 Disk Image [] Strength = 71@220: Applesoft BASIC program data, first line number %d [] Strength = 71@440: [] Strength = 71@484: Apple HFS/HFS+ resource fork [] Strength = 71@508: [] Strength = 71@518: iTunes cover art [] Strength = 71@39: APT cache data, version %u [] Strength = 71@47: APT cache data, version %u [] Strength = 71@1069: Zip archive data (empty) [application/zip] Strength = 71@1572: Gentoo binary package (XPAK) [] Strength = 71@1581: XBMC texture package [application/x-xbmc-xbt] Strength = 71@697: VGM Video Game Music dump v [audio/x-vgm] Strength = 71@800: GVOX Encore music, version 5.0 or above [] Strength = 71@804: GVOX Encore music, version < 5.0 [] Strength = 71@76: SAMtools BCF (Binary Call Format) [] Strength = 71@150: Sequence Alignment/Map (SAM), with header [] Strength = 71@7: BlackBerry RIM ETP file [] Strength = 71@19: compiled Java class data, [application/x-java-applet] Strength = 71@54: Mach-O universal binary with 1 architecture: [application/x-mach-binary] Strength = 71@118: ksh byte-code version %d [] Strength = 71@254: LZMA compressed data, [application/x-lzma] Strength = 71@285: [] Strength = 71@67: NES ROM image (UNIF v%d format) [application/x-nes-rom] Strength = 71@86: Famicom Disk System disk image: [application/x-fds-disk] Strength = 71@230: Sega 32X ROM image [application/x-genesis-32x-rom] Strength = 71@257: Sega Mega Drive / Genesis ROM image (SMD format): [application/x-genesis-rom] Strength = 71@263: Sega Mega Drive / Genesis ROM image (SMD format): [application/x-genesis-rom] Strength = 71@717: Nintendo GameCube embedded disc image: [application/x-gamecube-rom] Strength = 71@731: Nintendo Wii disc image (WBFS format): [application/x-wii-rom] Strength = 71@745: Nintendo GameCube disc image (CISO format): [application/x-wii-rom] Strength = 71@755: Nintendo GameCube disc image (GCZ format) [application/x-gamecube-rom] Strength = 71@796: Nintendo Wii SDK disc image: [application/x-wii-rom] Strength = 71@811: Nintendo 3DS Game Card image [] Strength = 71@472: Extensible storage engine [application/x-ms-ese] Strength = 71@503: Windows application compatibility Shim DataBase [application/x-ms-sdb] Strength = 71@7: Universal EFI binary with 1 architecture [] Strength = 71@13: Erlang BEAM file [] Strength = 71@1181: Syslinux bootloader (version 2.13 or older) [] Strength = 71@2026: Compressed ISO CD image [] Strength = 71@2286: GFS1 Filesystem [] Strength = 71@2317: XFS filesystem metadump image [] Strength = 71@2336: XFS filesystem metadump image [] Strength = 71@2350: JFS2 filesystem image [] Strength = 71@2409: UBIfs image [] Strength = 71@2418: UBI image, version %u [] Strength = 71@2429: NEC PC-88 disk image, name=%s [] Strength = 71@76: X11 SNF font data, LSB first [application/x-font-sfn] Strength = 71@93: GRUB2 font [application/x-font-pf2] Strength = 71@137: [] Strength = 71@148: [] Strength = 71@198: [] Strength = 71@202: [] Strength = 71@207: [] Strength = 71@317: TrueType [font/ttf] Strength = 71@49: Quake I or II world or extension [application/x-dzip] Strength = 71@155: GPG keybox database [] Strength = 71@212: [] Strength = 71@556: Award BIOS bitmap [image/x-award-bmp] Strength = 71@798: PCX [image/x-pcx] Strength = 71@1552: Sega PVR (Xbox) image: [] Strength = 71@1560: Sega PVR (Xbox) image: [] Strength = 71@1588: Sega GVR image: [] Strength = 71@1594: Sega GVR image: [] Strength = 71@1604: Lytro Light Field Picture [] Strength = 71@33: Compressed Google KML Document, including resources. [application/vnd.google-earth.kmz] Strength = 71@425: Device Tree Blob version %d [] Strength = 71@56: Emacs/XEmacs v%d byte-compiled Lisp data [application/x-elc] Strength = 71@243: Mach-O [application/x-mach-binary] Strength = 71@248: Mach-O [application/x-mach-binary] Strength = 71@467: Mac OSX datafork font, TrueType [] Strength = 71@14: WebM [video/webm] Strength = 71@48: Gridded binary (GRIB) version 1 [] Strength = 71@12: Micro Focus File with Header (DAT) [application/octet-stream] Strength = 71@16: Micro Focus File with Header (DAT) [application/octet-stream] Strength = 71@665: Microsoft Word for Macintosh 1.0 [application/msword] Strength = 71@717: Lotus 1-2-3 [application/vnd.lotus-1-2-3] Strength = 71@918: [] Strength = 71@990: [] Strength = 71@1011: Windows Recycle Bin INFO2 file (Win98 or below) [] Strength = 71@1014: Windows Recycle Bin INFO2 file (Win2k - WinXP) [] Strength = 71@1034: Delphi compiled form '%s' [] Strength = 71@1043: Windows shortcut file [] Strength = 71@1100: Norton Guide [] Strength = 71@1393: Windows Enhanced Metafile (EMF) image data [] Strength = 71@1407: %s system BIOS [] Strength = 71@46: MSX Moonblaster for MoonSound music [] Strength = 71@74: MSX SCMD Music file [] Strength = 71@207: MSX-BASIC extension ROM [] Strength = 71@251: [] Strength = 71@149: Palm OS dynamic library data "%s" [] Strength = 71@11: OpenStreetMap Protocolbuffer Binary Format [] Strength = 71@14: NEC PC-88 disk image, name=%s [] Strength = 71@129: Zenographics ZjStream printer data (big-endian) [] Strength = 71@131: Zenographics ZjStream printer data (little-endian) [] Strength = 71@11: ps database [] Strength = 71@33: Git pack [application/x-git] Strength = 71@15: Raspberry PI kernel image [] Strength = 71@20: QL OS dump data, [] Strength = 71@301: pcapng capture file [] Strength = 71@305: pcapng capture file [] Strength = 71@61: MySQL Maria control file [] Strength = 71@48: LG robot VR6[234]xx %dm^2 navigation [] Strength = 71@230: QEMU QCOW2 Image [] Strength = 71@29: VMS Alpha executable [] Strength = 71@33: MS Windows 32bit crash dump [] Strength = 71@64: System Deployment Image [application/x-ms-sdi] Strength = 71@129: Windows Error Report [text/plain] Strength = 71@173: MS [] Strength = 71@516: Windows setup INFormation [application/x-setupscript] Strength = 71@648: Windows NTbackup archive [] Strength = 71@19: WordPerfect macro [] Strength = 71@40: Xilinx RAW bitstream (.BIN) [] Strength = 71@10: YARA 3.x compiled rule set [] Strength = 71@63: , %s [] Strength = 70@10: RISC OS Chunk data [] Strength = 70@15: RISC OS AIF executable [] Strength = 70@19: RISC OS Draw file data [] Strength = 70@54: Glulx game data [] Strength = 70@7: Allegro datafile (packed) [] Strength = 70@8: Allegro datafile (not packed/autodetect) [] Strength = 70@9: Allegro datafile (appended exe data) [] Strength = 70@9: AmigaOS shared library [] Strength = 70@10: AmigaOS loadseg()ble executable/binary [] Strength = 70@11: AmigaOS object/library data [] Strength = 70@28: Future Composer 1.4 Module sound file [] Strength = 70@29: Future Composer 1.3 Module sound file [] Strength = 70@34: The Holy Noise Module sound file [] Strength = 70@45: AmigaOS outline tag [] Strength = 70@53: Rigid Disk Block [] Strength = 70@55: Amiga DOS disk [] Strength = 70@56: Amiga FFS disk [] Strength = 70@57: Amiga Inter DOS disk [] Strength = 70@58: Amiga Inter FFS disk [] Strength = 70@59: Amiga Fastdir DOS disk [] Strength = 70@60: Amiga Fastdir FFS disk [] Strength = 70@61: Kickstart disk [] Strength = 70@67: AmigaDOS script [] Strength = 70@68: AmigaDOS script [] Strength = 70@78: AMOS Basic sprite bank [] Strength = 70@80: AMOS Basic icon bank [] Strength = 70@82: AMOS Basic memory bank [] Strength = 70@86: AMOS Basic memory banks [] Strength = 70@169: Android sparse image [] Strength = 70@180: Android binary XML [] Strength = 70@11: Silicon Graphics movie file [video/x-sgi-movie] Strength = 70@13: Apple QuickTime [video/quicktime] Strength = 70@19: Apple QuickTime movie (unoptimized) [video/quicktime] Strength = 70@27: Apple QuickTime image (fast start) [image/x-quicktime] Strength = 70@31: Apple QuickTime compressed archive [application/x-quicktime-player] Strength = 70@36: ISO Media [] Strength = 70@713: MPEG ADIF, AAC [audio/x-hx-aac-adif] Strength = 70@861: DIF [] Strength = 70@868: Microsoft ASF [video/x-ms-asf] Strength = 70@872: MNG video data, [video/x-mng] Strength = 70@880: JNG video data, [video/x-jng] Strength = 70@999: Nullsoft Video [] Strength = 70@1004: REDCode Video [] Strength = 70@1009: MTV Multimedia File [] Strength = 70@1031: Sega FILM/CPK Multimedia, [] Strength = 70@1038: Nintendo THP Multimedia [] Strength = 70@1043: BBC Dirac Video [] Strength = 70@18: a.out little-endian 32-bit executable [] Strength = 70@22: a.out little-endian 32-bit pure executable [] Strength = 70@26: a.out little-endian 32-bit demand paged pure executable [] Strength = 70@38: a.out big-endian 32-bit executable [] Strength = 70@41: a.out big-endian 32-bit pure executable [] Strength = 70@44: a.out big-endian 32-bit demand paged executable [] Strength = 70@15: Apache Parquet [] Strength = 70@7: APL workspace (Ken's original?) [] Strength = 70@11: AppleSingle encoded Macintosh file [] Strength = 70@12: AppleDouble encoded Macintosh file [] Strength = 70@82: Apple ][ 2IMG Disk Image [] Strength = 70@258: Apple Mechanic font [] Strength = 70@328: CoreAudio Format audio file [] Strength = 70@335: Mac OS X Keychain File [] Strength = 70@339: Mac OS X Code Requirement [] Strength = 70@343: Mac OS X Code Requirement Set [] Strength = 70@347: Mac OS X Code Directory [] Strength = 70@352: Mac OS X Detached Code Signature (non-executable) [] Strength = 70@355: Mac OS X Detached Code Signature [] Strength = 70@512: Apple File System (APFS) [] Strength = 70@192: very old 32-bit-int little-endian archive [] Strength = 70@193: very old 32-bit-int big-endian archive [] Strength = 70@199: old 32-bit-int little-endian archive [] Strength = 70@201: old 32-bit-int big-endian archive [] Strength = 70@207: PDP-11 old archive [] Strength = 70@208: PDP-11 4.0 archive [] Strength = 70@215: apl workspace [] Strength = 70@220: System V Release 1 ar archive [application/x-archive] Strength = 70@334: ARC archive data, dynamic LZW [application/x-arc] Strength = 70@336: ARC archive data, squashed [application/x-arc] Strength = 70@338: ARC archive data, uncompressed [application/x-arc] Strength = 70@340: ARC archive data, packed [application/x-arc] Strength = 70@342: ARC archive data, squeezed [application/x-arc] Strength = 70@344: ARC archive data, crunched [application/x-arc] Strength = 70@347: PAK archive data [application/x-arc] Strength = 70@349: ARC+ archive data [application/x-arc] Strength = 70@351: HYP archive data [application/x-arc] Strength = 70@375: HPack archive data [] Strength = 70@377: HAP archive data [] Strength = 70@379: MDCD archive data [] Strength = 70@381: LIM archive data [] Strength = 70@387: BSArc archive data [] Strength = 70@400: ReSOF archive data [] Strength = 70@407: X1 archive data [] Strength = 70@409: CDC Codec archive data [] Strength = 70@417: ChArc archive data [] Strength = 70@451: DRY archive data [] Strength = 70@455: AR7 archive data [] Strength = 70@457: PPMZ archive data [] Strength = 70@569: MP3-Archiver archive data [] Strength = 70@571: ZET archive data [] Strength = 70@575: ARQ archive data [] Strength = 70@579: Terse archive data [] Strength = 70@586: ABComp archive data [] Strength = 70@592: InstallShield Z archive Data [] Strength = 70@604: BTS archive data [] Strength = 70@606: ELI 5750 archive data [] Strength = 70@608: QFC archive data [] Strength = 70@609: QFC archive data [] Strength = 70@615: LZS221 archive data [] Strength = 70@623: IMP archive data [] Strength = 70@627: Squish archive data [] Strength = 70@634: SBX archive data [] Strength = 70@645: InstallShield CAB [] Strength = 70@651: BlakHole archive data [] Strength = 70@653: BIX archive data [] Strength = 70@668: PFT archive data [] Strength = 70@672: PPMD archive data [] Strength = 70@676: MSXiE archive data [] Strength = 70@678: DeepFreezer archive data [] Strength = 70@680: DC archive data [] Strength = 70@687: Ai32 archive data [] Strength = 70@688: Ai32 archive data [] Strength = 70@696: DMS archive data [] Strength = 70@698: EPC archive data [] Strength = 70@704: ReDuq archive data [] Strength = 70@706: GCA archive data [] Strength = 70@716: WinHKI archive data [] Strength = 70@720: BSN archive data [] Strength = 70@721: BSN archive data [] Strength = 70@722: BSN archive data [] Strength = 70@731: SZip archive data [] Strength = 70@754: Xpack single archive data [] Strength = 70@828: HA archive data [] Strength = 70@838: HPACK archive data [] Strength = 70@1052: RAR archive data (<v1.5) [application/x-rar] Strength = 70@1057: squished archive data (Acorn RISCOS) [] Strength = 70@1061: UC2 archive data [] Strength = 70@1218: Zoo archive data [application/x-zoo] Strength = 70@1283: PARity archive data [] Strength = 70@1351: EET archive [application/x-eet] Strength = 70@1355: rzip compressed data [] Strength = 70@1371: dar archive, [] Strength = 70@1382: Symbian installation file [application/vnd.symbian.install] Strength = 70@1386: Symbian installation file (Symbian OS 9.x) [x-epoc/x-sisx-app] Strength = 70@1390: MoPaQ (MPQ) archive [] Strength = 70@1405: xar archive [application/x-xar] Strength = 70@1462: Parity Archive Volume Set [] Strength = 70@1467: Bacula volume [] Strength = 70@1481: ZPAQ file [] Strength = 70@1496: Norton GHost image [] Strength = 70@1528: Google Chrome extension [application/x-chrome-extension] Strength = 70@8: Aster*x [] Strength = 70@13: Aster*x Version 2 [] Strength = 70@11: Sun/NeXT audio data: [] Strength = 70@49: DEC audio data: [] Strength = 70@86: Standard MIDI data [audio/midi] Strength = 70@94: Creative Music (CMF) data [audio/x-unknown] Strength = 70@106: MultiTrack sound data [] Strength = 70@111: Extended MOD sound data, [] Strength = 70@119: RealAudio sound file [audio/x-pn-realaudio] Strength = 70@140: ScreamTracker III Module sound data [] Strength = 70@168: MikMod UNI format module sound data [] Strength = 70@181: 4-channel Protracker module sound data [audio/x-mod] Strength = 70@185: 4-channel Protracker module sound data [audio/x-mod] Strength = 70@189: 4-channel Startracker module sound data [audio/x-mod] Strength = 70@193: 8-channel Startracker module sound data [audio/x-mod] Strength = 70@197: 4-channel Fasttracker module sound data [audio/x-mod] Strength = 70@201: 6-channel Fasttracker module sound data [audio/x-mod] Strength = 70@205: 8-channel Fasttracker module sound data [audio/x-mod] Strength = 70@209: 8-channel Octalyser module sound data [audio/x-mod] Strength = 70@213: 8-channel Octalyzer module sound data [audio/x-mod] Strength = 70@220: 16-channel Taketracker module sound data [audio/x-mod] Strength = 70@224: 32-channel Taketracker module sound data [audio/x-mod] Strength = 70@237: PlaySID v2.2+ (AMIGA) sidtune [] Strength = 70@246: RSID sidtune PlaySID compatible [] Strength = 70@257: IRCAM file (VAX little-endian) [] Strength = 70@258: IRCAM file (VAX big-endian) [] Strength = 70@259: IRCAM file (Sun big-endian) [] Strength = 70@260: IRCAM file (Sun little-endian) [] Strength = 70@261: IRCAM file (MIPS little-endian) [] Strength = 70@262: IRCAM file (MIPS big-endian) [] Strength = 70@263: IRCAM file (NeXT big-endian) [] Strength = 70@264: IRCAM file (NeXT big-endian) [] Strength = 70@265: IRCAM file (NeXT little-endian) [] Strength = 70@274: Audio Visual Research file, [] Strength = 70@319: Extended NES Sound File [] Strength = 70@341: Impulse Tracker module sound data - [audio/x-mod] Strength = 70@348: Imago Orpheus module sound data - [] Strength = 70@355: Impulse Tracker Sample [] Strength = 70@360: Impulse Tracker Instrument [] Strength = 70@376: Scream Tracker Sample [] Strength = 70@389: MED music file, version 0 [] Strength = 70@390: OctaMED Pro music file, version 1 [] Strength = 70@391: OctaMED Soundstudio music file, version 3 [] Strength = 70@394: Symphonie SymMOD music file [] Strength = 70@415: DIGI Booster Pro Module [] Strength = 70@420: FaceTheMusic module [] Strength = 70@426: Xtracker DMF Module [] Strength = 70@430: Dynamic Studio Module DSM [] Strength = 70@431: DigiTrekker DTM Module [] Strength = 70@432: DigiTrakker MDL Module [] Strength = 70@433: Protracker Studio PSM Module [] Strength = 70@434: Poly Tracker PTM Module [] Strength = 70@436: MadTracker 2.0 Module MT2 [] Strength = 70@438: RTM Module [] Strength = 70@450: Yamaha SMAF file [] Strength = 70@458: FLAC audio bitstream data [audio/flac] Strength = 70@502: VBOX voice message data [] Strength = 70@506: RBS Song file [] Strength = 70@521: Monkey's Audio compressed format [audio/x-ape] Strength = 70@564: Surprise! Adlib Tracker [] Strength = 70@567: eXotic ADlib [] Strength = 70@571: FM Kingtracker Song [] Strength = 70@617: SNDH Atari ST music [] Strength = 70@655: Musepack audio (MPCK) [audio/x-musepack] Strength = 70@670: SoundFX Module sound file [] Strength = 70@681: SuperCollider3 Synth Definition file, [] Strength = 70@687: True Audio Lossless Audio [] Strength = 70@692: WavPack Lossless Audio [] Strength = 70@952: IBK instrument data [] Strength = 70@953: IBK instrument data, 2 operators [] Strength = 70@954: IBK instrument data, 4 operators [] Strength = 70@1040: Nintendo Wii BRSTM audio file [audio/x-brstm] Strength = 70@1068: Nintendo 3DS BCSTM audio file [audio/x-bcstm] Strength = 70@1081: Nintendo Wii U BFSTM audio file [audio/x-bfstm] Strength = 70@1106: Nintendo 3DS BCWAV audio file [audio/x-bcwav] Strength = 70@8: BFLT executable [] Strength = 70@22: SAMtools TBI (Tabix index format) [] Strength = 70@43: SAMtools BAM (Binary Sequence Alignment/Map) [] Strength = 70@54: SAMtools BAI (BAM indexing format) [] Strength = 70@61: CRAM [] Strength = 70@14: Biosig/Axon Binary format [biosig/abf2] Strength = 70@22: Biosig/Axon Text fomrat [biosig/atf] Strength = 70@25: Biosig/Axona file format [biosig/axona] Strength = 70@27: Biosig/Axona file format [biosig/axona] Strength = 70@33: Biosig/AXG [] Strength = 70@34: Biosig/AXG [biosig/axg] Strength = 70@72: Biosig/DEMG [biosig/demg] Strength = 70@87: Biosig/IgorPro ITX file [biosig/igorpro] Strength = 70@103: Biosig/NEX [biosig/nex1] Strength = 70@106: Biosig/Plexon v1.0 [] Strength = 70@110: Biosig/RHD2000: Intan RHD2000 format [] Strength = 70@136: Biosig/Walter Graphtek [] Strength = 70@137: Biosig/Walter Graphtek [] Strength = 70@138: Biosig/Walter Graphtek [biosig/walter-graphtek] Strength = 70@15: 68k Blit mpx/mux executable [] Strength = 70@6: i960 b.out relocatable object [] Strength = 70@9: 386 compact demand paged pure executable [] Strength = 70@14: SPARC demand paged [] Strength = 70@23: SPARC pure [] Strength = 70@29: SPARC [] Strength = 70@6: Chiasmus encrypted data [] Strength = 70@8: D64 Image [] Strength = 70@9: D71 Image [] Strength = 70@10: D81 Image [] Strength = 70@12: X64 Image [] Strength = 70@18: ARC archive (c64) [] Strength = 70@28: WRAptor packer (c64) [] Strength = 70@53: GoatTracker 2 song [] Strength = 70@143: Bentley/Intergraph MicroStation DGN cell library [] Strength = 70@144: Bentley/Intergraph MicroStation DGN vector CAD [] Strength = 70@145: Bentley/Intergraph MicroStation DGN vector CAD [] Strength = 70@34: JAR compressed with pack200, [] Strength = 70@40: JAR compressed with pack200, [] Strength = 70@9: cisco IOS microcode [] Strength = 70@11: cisco IOS experimental microcode [] Strength = 70@64: CLIPPER instruction trace [] Strength = 70@65: CLIPPER instruction profile [] Strength = 70@155: lzip compressed data [application/x-lzip] Strength = 70@234: Amiga xpkf.library compressed data [] Strength = 70@235: Power Packer 1.1 compressed data [] Strength = 70@236: Power Packer 2.0 compressed data, [] Strength = 70@268: LRZIP compressed data [] Strength = 70@274: LZ4 compressed data (v1.4+) [application/x-lz4] Strength = 70@277: LZ4 compressed data (v1.0-v1.3) [application/x-lz4] Strength = 70@279: LZ4 compressed data (v0.1-v0.9) [application/x-lz4] Strength = 70@310: Zstandard compressed data (v0.2) [application/x-zstd] Strength = 70@312: Zstandard compressed data (v0.3) [application/x-zstd] Strength = 70@314: Zstandard compressed data (v0.4) [application/x-zstd] Strength = 70@316: Zstandard compressed data (v0.5) [application/x-zstd] Strength = 70@318: Zstandard compressed data (v0.6) [application/x-zstd] Strength = 70@320: Zstandard compressed data (v0.7) [application/x-zstd] Strength = 70@323: Zstandard compressed data (v0.8+) [application/x-zstd] Strength = 70@328: Zstandard dictionary [application/x-zstd-dictionary] Strength = 70@341: rzip compressed data [] Strength = 70@346: FreeArc archive <http://freearc.org> [] Strength = 70@349: DACT compressed data [] Strength = 70@357: Valve Pak file [] Strength = 70@385: Softlib archive [] Strength = 70@391: lzfse encoded, no compression [] Strength = 70@392: lzfse compressed, uncompressed tables [] Strength = 70@393: lzfse compressed, compressed tables [] Strength = 70@394: lzfse encoded, lzvn compressed [] Strength = 70@49: NES ROM image (iNES) [application/x-nes-rom] Strength = 70@54: NES ROM image (Wii U Virtual Console) [application/x-nes-rom] Strength = 70@102: NES ROM image (Nintendo 3DS Virtual Console) [application/x-nes-rom] Strength = 70@388: Sega Dreamcast VMU game image [] Strength = 70@389: Dream Animator file [] Strength = 70@510: Microsoft Xbox executable [] Strength = 70@535: XIP, Microsoft Xbox data [] Strength = 70@536: XTF, Microsoft Xbox data [] Strength = 70@551: Microsoft Xbox 360 executable [] Strength = 70@629: SNES9x input recording [] Strength = 70@683: ScummVM savegame [] Strength = 70@707: Nintendo GameCube disc image: [application/x-gamecube-rom] Strength = 70@724: Nintendo Wii disc image: [] Strength = 70@781: Nintendo [] Strength = 70@873: Nintendo 3DS [] Strength = 70@895: Nintendo 3DS SMDH file [] Strength = 70@909: Nintendo 3DS Homebrew Application (3DSX) [] Strength = 70@12: Convex old-style object [] Strength = 70@14: Convex old-style demand paged executable [] Strength = 70@16: Convex old-style pre-paged executable [] Strength = 70@18: Convex old-style pre-paged, non-swapped executable [] Strength = 70@20: Core file [] Strength = 70@33: dump format, 4.2 or 4.3 BSD (IDC compatible) [] Strength = 70@34: dump format, Convex Storage Manager by-reference dump [] Strength = 70@39: Convex SOFF [] Strength = 70@57: Convex SOFF core [] Strength = 70@59: Convex SOFF checkpoint [] Strength = 70@29: GCC gcno coverage (-ftest-coverage), [] Strength = 70@34: GCC gcno coverage (-ftest-coverage), [] Strength = 70@41: GCC gcda coverage (-fprofile-arcs), [] Strength = 70@46: GCC gcda coverage (-fprofile-arcs), [] Strength = 70@6: Cracklib password index, little endian [] Strength = 70@10: Cracklib password index, big endian [] Strength = 70@9: Common Trace Format (CTF) trace data (LE) [] Strength = 70@10: Common Trace Format (CTF) trace data (BE) [] Strength = 70@13: Common Trace Format (CTF) packetized metadata (LE) [] Strength = 70@16: Common Trace Format (CTF) packetized metadata (BE) [] Strength = 70@6: Map file for the AssaultCube FPS game [] Strength = 70@7: Map file for cube and cube2 engine games [] Strength = 70@6: DACT compressed data [] Strength = 70@12: GNU dbm 1.x or ndbm database, big endian, 32-bit [application/x-gdbm] Strength = 70@14: GNU dbm 1.x or ndbm database, big endian, old [application/x-gdbm] Strength = 70@16: GNU dbm 1.x or ndbm database, big endian, 64-bit [application/x-gdbm] Strength = 70@18: GNU dbm 1.x or ndbm database, little endian, 32-bit [application/x-gdbm] Strength = 70@20: GNU dbm 1.x or ndbm database, little endian, old [application/x-gdbm] Strength = 70@22: GNU dbm 1.x or ndbm database, little endian, 64-bit [application/x-gdbm] Strength = 70@24: GNU dbm 2.x database [application/x-gdbm] Strength = 70@35: Berkeley DB [application/x-dbm] Strength = 70@46: Berkeley DB [] Strength = 70@56: Berkeley DB 1.85/1.86 [] Strength = 70@58: Berkeley DB 1.85/1.86 [] Strength = 70@60: Berkeley DB 1.85/1.86 [] Strength = 70@63: Berkeley DB [] Strength = 70@65: Berkeley DB [] Strength = 70@67: Berkeley DB [] Strength = 70@70: Berkeley DB [] Strength = 70@72: Berkeley DB [] Strength = 70@74: Berkeley DB [] Strength = 70@77: Berkeley DB [] Strength = 70@79: Berkeley DB [] Strength = 70@81: Berkeley DB [] Strength = 70@85: Berkeley DB [] Strength = 70@87: Berkeley DB [] Strength = 70@89: Berkeley DB [] Strength = 70@95: RRDTool DB [] Strength = 70@515: SE Linux policy [] Strength = 70@587: Zope Object Database File Storage v3 (data) [] Strength = 70@588: Zope Object Database File Storage v4 (data) [] Strength = 70@591: Zope Object Database Client Cache File (data) [] Strength = 70@594: IDA (Interactive Disassembler) database [] Strength = 70@8: Maxis Database Packed File [] Strength = 70@36: rdiff network-delta data [] Strength = 70@38: rdiff network-delta signature data [] Strength = 70@50: X image [] Strength = 70@65: new-fs dump file (big endian), [] Strength = 70@68: old-fs dump file (big endian), [] Strength = 70@76: old-fs dump file (little endian), [] Strength = 70@80: new-fs dump file (ufs2, big endian), [] Strength = 70@83: new-fs dump file (ufs2, little endian), [] Strength = 70@6: EBML file [] Strength = 70@6: T602 document data, [] Strength = 70@9: Psion Series 5 [] Strength = 70@36: Psion Series 5 ROM multi-bitmap image [] Strength = 70@38: Psion Series 5 [] Strength = 70@48: Psion Series 5 binary: [] Strength = 70@62: Psion Series 5 executable [] Strength = 70@7: ESRI Shapefile [] Strength = 70@187: PC formatted floppy with no filesystem [] Strength = 70@1140: FATX filesystem data [] Strength = 70@1148: Netboot image, [] Strength = 70@1154: OS/2 Boot Manager [] Strength = 70@1165: pxelinux loader (version 2.13 or older) [] Strength = 70@1167: pxelinux loader [] Strength = 70@1169: pxelinux loader (version 3.70 or newer) [] Strength = 70@1554: NTFS [] Strength = 70@1560: NTFS [] Strength = 70@1587: Unix Fast File system [v1] (little-endian), [] Strength = 70@1603: Unix Fast File system [v2] (little-endian) [] Strength = 70@1623: Unix Fast File system [v2] (little-endian) [] Strength = 70@1643: Unix Fast File system [v1] (big-endian), [] Strength = 70@1663: Unix Fast File system [v2] (big-endian) [] Strength = 70@1683: Unix Fast File system [v2] (big-endian) [] Strength = 70@1757: F2FS filesystem [] Strength = 70@1813: SGI disk label (volume header) [] Strength = 70@1816: SGI XFS filesystem data [] Strength = 70@1824: Atari-ST Minix kernel image [] Strength = 70@2029: Linux Compressed ROM File System data, little endian [] Strength = 70@2039: Linux Compressed ROM File System data, big endian [] Strength = 70@2061: Linux Journalled Flash File system, little endian [] Strength = 70@2062: Linux Journalled Flash File system, big endian [] Strength = 70@2075: u-boot legacy uImage, [] Strength = 70@2150: Squashfs filesystem, big endian, [] Strength = 70@2173: Squashfs filesystem, little endian, [] Strength = 70@2340: Delta ISO data, [] Strength = 70@2360: LFS filesystem image [] Strength = 70@54: Macromedia Flash Video [video/x-flv] Strength = 70@7: FLIF [] Strength = 70@71: X11 SNF font data, MSB first [application/x-font-sfn] Strength = 70@103: X11 Portable Compiled Font data, [] Strength = 70@121: libGrx font data, [] Strength = 70@126: DOS code page font data collection [] Strength = 70@127: DOS code page font data [] Strength = 70@128: DOS code page font data (from Linux?) [] Strength = 70@185: Portable Font Resource font data (new) [] Strength = 70@187: Portable Font Resource font data (old) [] Strength = 70@343: OpenType font data [application/vnd.ms-opentype] Strength = 70@373: Web Open Font Format [] Strength = 70@378: Web Open Font Format (Version 2) [] Strength = 70@35: FrameMaker MML file [application/x-mif] Strength = 70@77: FreeBSD/i386 [] Strength = 70@87: FreeBSD/i386 pure [] Strength = 70@97: FreeBSD/i386 demand paged [] Strength = 70@107: FreeBSD/i386 compact demand paged [] Strength = 70@130: ld.so hints file (Little Endian [] Strength = 70@133: ld.so hints file (Big Endian [] Strength = 70@8: Quake II 3D Model file, [] Strength = 70@18: Quake [] Strength = 70@22: Quake II SP2 sprite file [] Strength = 70@189: doom main IWAD data [] Strength = 70@191: doom patch PWAD data [] Strength = 70@209: Warcraft III map file [] Strength = 70@297: Unreal Engine Package, [] Strength = 70@6: GCC precompiled header [] Strength = 70@10: gconv module configuration cache data [] Strength = 70@30: Knudsen seismic KEL binary (KEB) - [] Strength = 70@68: XSE multibeam [] Strength = 70@82: Caris multibeam sonar related data [] Strength = 70@108: Surfer 6 binary grid file [] Strength = 70@121: LIDAR point data records [] Strength = 70@6: GEOS [] Strength = 70@35: GIMP pattern data, [] Strength = 70@43: GIMP brush data [] Strength = 70@8: glibc locale file LC_CTYPE [] Strength = 70@9: glibc locale file LC_NUMERIC [] Strength = 70@10: glibc locale file LC_TIME [] Strength = 70@11: glibc locale file LC_COLLATE [] Strength = 70@12: glibc locale file LC_MONETARY [] Strength = 70@13: glibc locale file LC_MESSAGES [] Strength = 70@14: glibc locale file LC_ALL [] Strength = 70@15: glibc locale file LC_PAPER [] Strength = 70@16: glibc locale file LC_NAME [] Strength = 70@17: glibc locale file LC_ADDRESS [] Strength = 70@18: glibc locale file LC_TELEPHONE [] Strength = 70@19: glibc locale file LC_MEASUREMENT [] Strength = 70@20: glibc locale file LC_IDENTIFICATION [] Strength = 70@36: GStreamer binary registry [] Strength = 70@15: GNU message catalog (little endian), [] Strength = 70@96: GNU message catalog (big endian), [application/x-gettext-translation] Strength = 70@119: GPG key trust database [] Strength = 70@10: Khronos SPIR-V binary, big-endian [] Strength = 70@14: Khronos SPIR-V binary, little-endian [] Strength = 70@48: TML 0123 byte-order format [] Strength = 70@49: TML 1032 byte-order format [] Strength = 70@50: TML 2301 byte-order format [] Strength = 70@51: TML 3210 byte-order format [] Strength = 70@53: PA-RISC1.1 relocatable object [] Strength = 70@54: PA-RISC1.1 executable [] Strength = 70@59: PA-RISC1.1 shared executable [] Strength = 70@64: PA-RISC1.1 demand-load executable [] Strength = 70@69: PA-RISC1.1 shared library [] Strength = 70@72: PA-RISC1.1 dynamic load library [] Strength = 70@76: PA-RISC2.0 relocatable object [] Strength = 70@78: PA-RISC2.0 executable [] Strength = 70@83: PA-RISC2.0 shared executable [] Strength = 70@88: PA-RISC2.0 demand-load executable [] Strength = 70@93: PA-RISC2.0 shared library [] Strength = 70@96: PA-RISC2.0 dynamic load library [] Strength = 70@100: PA-RISC1.0 relocatable object [] Strength = 70@102: PA-RISC1.0 executable [] Strength = 70@107: PA-RISC1.0 shared executable [] Strength = 70@112: PA-RISC1.0 demand-load executable [] Strength = 70@117: PA-RISC1.0 shared library [] Strength = 70@120: PA-RISC1.0 dynamic load library [] Strength = 70@124: HP s500 relocatable executable [] Strength = 70@127: HP s500 executable [] Strength = 70@130: HP s500 pure executable [] Strength = 70@134: HP s200 pure executable [] Strength = 70@141: HP s200 executable [] Strength = 70@148: HP s200 demand-load executable [] Strength = 70@155: HP s200 relocatable executable [] Strength = 70@162: HP s200 (2.x release) pure executable [] Strength = 70@166: HP s200 (2.x release) executable [] Strength = 70@170: HP s200 shared library [] Strength = 70@175: HP s200 dynamic load library [] Strength = 70@181: HP old archive [] Strength = 70@182: HP s200 old archive [] Strength = 70@183: HP s200 old archive [] Strength = 70@184: HP s500 old archive [] Strength = 70@186: HP core file [] Strength = 70@188: HP-WINDOWS font [] Strength = 70@195: compiled Lisp [] Strength = 70@204: HP [] Strength = 70@17: AIX compiled message catalog [] Strength = 70@20: AIX backup/restore format file [] Strength = 70@21: AIX backup/restore format file [] Strength = 70@13: IFF data [] Strength = 70@225: MicroDesign data [] Strength = 70@228: MicroDesign page data [] Strength = 70@234: NIFF image data [image/x-niff] Strength = 70@414: Big TIFF image data, big-endian [image/tiff] Strength = 70@416: Big TIFF image data, little-endian [image/tiff] Strength = 70@495: CMU window manager raster image data [] Strength = 70@504: Artisan image data [] Strength = 70@521: GKS Metafile [] Strength = 70@543: structured fax file [] Strength = 70@636: Sun raster image data [] Strength = 70@670: FIT image data [] Strength = 70@675: FIT image data [] Strength = 70@712: DICOM medical imaging data [application/dicom] Strength = 70@743: PDS image data [] Strength = 70@755: Atari ST STAD bitmap image data (hor) [] Strength = 70@758: Atari ST STAD bitmap image data (vert) [] Strength = 70@823: Adobe Photoshop Image [image/vnd.adobe.photoshop] Strength = 70@849: National Imagery Transmission Format [] Strength = 70@917: GEM Metafile data [] Strength = 70@957: KISS/GS [] Strength = 70@990: Squeak image data [] Strength = 70@1014: DCX multi-page PCX image data [] Strength = 70@1019: Cineon image data [] Strength = 70@1041: Minolta Dimage camera raw image data [] Strength = 70@1061: OpenEXR image data, [image/x-exr] Strength = 70@1100: DPX image data, big-endian, [image/x-dpx] Strength = 70@1103: DPX image data, little-endian, [image/x-dpx] Strength = 70@1125: NetCDF Data Format data [] Strength = 70@1130: Hierarchical Data Format (version 4) data [application/x-hdf] Strength = 70@1150: Cartesian Perceptual Compression image [image/x-cpi] Strength = 70@1161: OLPC firmware icon image data [] Strength = 70@1167: Cytovision Metaphases file [] Strength = 70@1168: Cytovision Karyotype file [] Strength = 70@1169: Cytovision FISH Probe file [] Strength = 70@1170: Cytovision FLEX file [] Strength = 70@1171: Cytovision FLEX file [] Strength = 70@1172: Cytovision RATS file [] Strength = 70@1186: PCO B16 image data [] Strength = 70@1237: X11 cursor [] Strength = 70@1242: Olympus ORF raw image data, big-endian [image/x-olympus-orf] Strength = 70@1244: Olympus ORF raw image data, little-endian [image/x-olympus-orf] Strength = 70@1246: Olympus ORF raw image data, little-endian [image/x-olympus-orf] Strength = 70@1275: Foveon X3F raw image data [image/x-x3f] Strength = 70@1284: Paint.NET image data [image/x-paintnet] Strength = 70@1289: ISO/IEC 19794-2 Format Minutiae Record (FMR) [] Strength = 70@1347: BPG (Better Portable Graphics) [image/bpg] Strength = 70@1352: Mac OS X icon [image/x-icns] Strength = 70@1363: TIM image, [] Strength = 70@1384: MDEC video stream, [] Strength = 70@1583: Sega GVR image: [] Strength = 70@1627: ARRI ARI image data, [] Strength = 70@1749: Valve Texture Format [] Strength = 70@1763: Valve Texture Format (PS3) [] Strength = 70@1774: ASTC [] Strength = 70@1795: icrosoft Paint image data (version 1.x) [] Strength = 70@1798: Microsoft Paint image data (version 2.0) [] Strength = 70@1888: PVR 3.0 texture: [] Strength = 70@1960: Microsoft Xbox XPR0 texture [] Strength = 70@68: Intel serial flash for ICH/PCH ROM <= 5 or 3400 series A-step [] Strength = 70@69: Intel serial flash for PCH ROM [] Strength = 70@6: Interleaf saved data [] Strength = 70@58: ispell [] Strength = 70@6: ISO Zipped file [] Strength = 70@13: Java KeyStore [application/x-java-keystore] Strength = 70@15: Java JCE KeyStore [application/x-java-jce-keystore] Strength = 70@32: Java jmod module version 1.0 [application/x-java-jmod] Strength = 70@37: Java module image (big endian) [] Strength = 70@42: Java module image (little endian) [] Strength = 70@98: JPEG image data, HSI proprietary [] Strength = 70@118: JPEG 2000 codestream [] Strength = 70@11: Keepass password database [] Strength = 70@44: Kerberos Keytab file [] Strength = 70@6: DEC SRC Virtual Paper Lectern file [] Strength = 70@16: Linux/i386 impure executable (OMAGIC) [] Strength = 70@18: Linux/i386 pure executable (NMAGIC) [] Strength = 70@20: Linux/i386 demand-paged executable (ZMAGIC) [] Strength = 70@22: Linux/i386 demand-paged executable (QMAGIC) [] Strength = 70@28: Linux-8086 impure executable [] Strength = 70@30: Linux-8086 executable [] Strength = 70@33: Linux-8086 object file [] Strength = 70@35: Minix-386 impure executable [] Strength = 70@37: Minix-386 executable [] Strength = 70@39: Minix-386 NSYM/GNU executable [] Strength = 70@49: Linux/i386 LILO boot/chain loader [] Strength = 70@137: Linux kernel [] Strength = 70@149: User-mode Linux COW file [] Strength = 70@189: Linux [] Strength = 70@212: Linux kernel ARM boot executable zImage (little-endian) [] Strength = 70@215: Linux kernel ARM boot executable zImage (big-endian) [] Strength = 70@219: Linux-Dev86 executable, headerless [] Strength = 70@223: Linux-8086 executable [] Strength = 70@245: SYSLINUX' LSS16 image data [image/x-lss16] Strength = 70@251: User-Mode-Linux's Copy-On-Write disk image [] Strength = 70@256: SE Linux policy [] Strength = 70@335: LVM Snapshot (CopyOnWrite store) [] Strength = 70@342: SE Linux policy [] Strength = 70@435: locale archive [] Strength = 70@449: Linux Software RAID [] Strength = 70@453: Linux Software RAID [] Strength = 70@476: iproute2 routes dump [] Strength = 70@477: iproute2 addresses dump [] Strength = 70@482: CRIU image file v1.1 [] Strength = 70@483: CRIU service file [] Strength = 70@484: CRIU inventory [] Strength = 70@67: CLISP memory image data [] Strength = 70@68: CLISP memory image data, other endian [] Strength = 70@71: MIT scheme (library?) [] Strength = 70@8: LLVM byte-codes, uncompressed [] Strength = 70@13: LLVM bitcode, wrapper [] Strength = 70@21: LLVM IR bitcode [] Strength = 70@19: Lua bytecode, [] Strength = 70@14: StuffIt Archive (data) [application/x-stuffit] Strength = 70@18: StuffIt Deluxe (data) [] Strength = 70@350: SPSS Portable File [] Strength = 70@353: SPSS System File [] Strength = 70@356: SPSS System File [] Strength = 70@7: magic binary file for file(1) cmd [] Strength = 70@9: magic binary file for file(1) cmd [] Strength = 70@36: Transport Neutral Encapsulation Format [application/vnd.ms-tnef] Strength = 70@48: JAM message area header file [] Strength = 70@9: FIT Map data [] Strength = 70@17: Maple help database [] Strength = 70@39: Maple something [] Strength = 70@34: Mathematica notebook version 2.x [] Strength = 70@10: Mercurial changeset bundle [] Strength = 70@8: Mirage Assembler m.out executable [] Strength = 70@38: Mini DuMP crash report [application/x-dmp] Strength = 70@6: MLSSA datafile, [] Strength = 70@6: MMDF mailbox [] Strength = 70@60: raw modem data [] Strength = 70@42: Atari ST M68K contiguous executable [] Strength = 70@47: Atari ST M68K non-contig executable [] Strength = 70@33: Mozilla archive omni.ja [application/x-zip] Strength = 70@489: DR-DOS executable (COM) [] Strength = 70@572: FREE-DOS executable (COM), UPX compressed [application/x-dosexec] Strength = 70@575: FREE-DOS executable (COM), UPX compressed [application/x-dosexec] Strength = 70@658: Microsoft Word Document [application/msword] Strength = 70@686: Microsoft WinWord 2.0 Document [application/msword] Strength = 70@692: Microsoft WinWord 2.0 Document [application/msword] Strength = 70@787: Lotus [application/vnd.lotus-1-2-3] Strength = 70@877: Windows metafile [image/wmf] Strength = 70@880: Windows metafile [image/wmf] Strength = 70@883: Windows metafile [image/wmf] Strength = 70@1022: Borland Delphi .DCU file [] Strength = 70@1027: TurboC BGI file [] Strength = 70@1028: TurboC Font file [] Strength = 70@1038: Windows 3.x .GRP file [] Strength = 70@1081: DOS EPS Binary File [image/x-eps] Strength = 70@1092: TNEF [application/vnd.ms-tnef] Strength = 70@1111: 4DOS help file [] Strength = 70@1367: InstallShield Cabinet archive data [] Strength = 70@23: Microsoft Visual C library [] Strength = 70@24: Microsoft Visual C library [] Strength = 70@25: Microsoft Visual C library [] Strength = 70@65: MSVC .bsc [] Strength = 70@23: KSS music file v1.03 [] Strength = 70@31: KSS music file v1.20 [] Strength = 70@12: National Instruments, [] Strength = 70@24: National Instruments, VXI File, data [] Strength = 70@7: NekoVM bytecode [] Strength = 70@57: a.out NetBSD/i386 demand paged [] Strength = 70@60: a.out NetBSD/i386 pure [] Strength = 70@63: a.out NetBSD/i386 [] Strength = 70@66: a.out NetBSD/i386 core [] Strength = 70@69: a.out NetBSD/m68k demand paged [] Strength = 70@72: a.out NetBSD/m68k pure [] Strength = 70@75: a.out NetBSD/m68k [] Strength = 70@78: a.out NetBSD/m68k core [] Strength = 70@81: a.out NetBSD/m68k4k demand paged [] Strength = 70@84: a.out NetBSD/m68k4k pure [] Strength = 70@87: a.out NetBSD/m68k4k [] Strength = 70@90: a.out NetBSD/m68k4k core [] Strength = 70@93: a.out NetBSD/ns32532 demand paged [] Strength = 70@96: a.out NetBSD/ns32532 pure [] Strength = 70@99: a.out NetBSD/ns32532 [] Strength = 70@102: a.out NetBSD/ns32532 core [] Strength = 70@105: a.out NetBSD/powerpc core [] Strength = 70@108: a.out NetBSD/SPARC demand paged [] Strength = 70@111: a.out NetBSD/SPARC pure [] Strength = 70@114: a.out NetBSD/SPARC [] Strength = 70@117: a.out NetBSD/SPARC core [] Strength = 70@120: a.out NetBSD/pmax demand paged [] Strength = 70@123: a.out NetBSD/pmax pure [] Strength = 70@126: a.out NetBSD/pmax [] Strength = 70@129: a.out NetBSD/pmax core [] Strength = 70@132: a.out NetBSD/vax 1k demand paged [] Strength = 70@135: a.out NetBSD/vax 1k pure [] Strength = 70@138: a.out NetBSD/vax 1k [] Strength = 70@141: a.out NetBSD/vax 1k core [] Strength = 70@144: a.out NetBSD/vax 4k demand paged [] Strength = 70@147: a.out NetBSD/vax 4k pure [] Strength = 70@150: a.out NetBSD/vax 4k [] Strength = 70@153: a.out NetBSD/vax 4k core [] Strength = 70@159: ECOFF NetBSD/alpha binary [] Strength = 70@162: a.out NetBSD/alpha core [] Strength = 70@166: a.out NetBSD/mips demand paged [] Strength = 70@170: a.out NetBSD/mips pure [] Strength = 70@173: a.out NetBSD/mips [] Strength = 70@176: a.out NetBSD/mips core [] Strength = 70@179: a.out NetBSD/arm32 demand paged [] Strength = 70@182: a.out NetBSD/arm32 pure [] Strength = 70@185: a.out NetBSD/arm32 [] Strength = 70@190: a.out NetBSD/arm core [] Strength = 70@194: NetBSD kernel core file [] Strength = 70@13: Netscape Communicator address book [] Strength = 70@8: NeWS bitmap font [] Strength = 70@9: NeWS font family [] Strength = 70@10: scalable OpenFont binary [] Strength = 70@11: encrypted scalable OpenFont binary [] Strength = 70@12: X11/NeWS bitmap font [] Strength = 70@13: X11/NeWS font family [] Strength = 70@6: NItpicker Flow File [] Strength = 70@14: OLF [] Strength = 70@7: OSF/Rose object [] Strength = 70@128: A GutenPalm zTXT e-book [] Strength = 70@150: Palm OS operating system patch data [] Strength = 70@6: PDP-11 single precision APL workspace [] Strength = 70@7: PDP-11 double precision APL workspace [] Strength = 70@64: perl Storable (v0.7) data [] Strength = 70@146: PGP RSA encrypted session key - [] Strength = 70@163: PGP RSA encrypted session key - [] Strength = 70@180: PGP RSA encrypted session key - [] Strength = 70@197: PGP RSA encrypted session key - [] Strength = 70@7: Plan 9 executable, Motorola 68k [] Strength = 70@8: Plan 9 executable, Intel 386 [] Strength = 70@9: Plan 9 executable, Intel 960 [] Strength = 70@10: Plan 9 executable, SPARC [] Strength = 70@11: Plan 9 executable, MIPS R3000 [] Strength = 70@12: Plan 9 executable, AT&T DSP 3210 [] Strength = 70@13: Plan 9 executable, MIPS R4000 BE [] Strength = 70@14: Plan 9 executable, AMD 29000 [] Strength = 70@15: Plan 9 executable, ARM 7-something [] Strength = 70@16: Plan 9 executable, PowerPC [] Strength = 70@17: Plan 9 executable, MIPS R4000 LE [] Strength = 70@18: Plan 9 executable, DEC Alpha [] Strength = 70@33: DOS EPS Binary File [] Strength = 70@115: RST-format raster font data [] Strength = 70@10: Pulsar POP3 daemon mailbox cache file. [] Strength = 70@14: Password Safe V3 database [] Strength = 70@8: Pyramid 90x family executable [] Strength = 70@9: Pyramid 90x family pure executable [] Strength = 70@11: Pyramid 90x family demand paged pure executable [] Strength = 70@13: python 1.5/1.6 byte-compiled [] Strength = 70@14: python 2.0 byte-compiled [] Strength = 70@15: python 2.1 byte-compiled [] Strength = 70@16: python 2.2 byte-compiled [] Strength = 70@17: python 2.3 byte-compiled [] Strength = 70@18: python 2.4 byte-compiled [] Strength = 70@19: python 2.5 byte-compiled [] Strength = 70@20: python 2.6 byte-compiled [] Strength = 70@21: python 2.7 byte-compiled [] Strength = 70@22: python 3.0 byte-compiled [] Strength = 70@23: python 3.1 byte-compiled [] Strength = 70@24: python 3.2 byte-compiled [] Strength = 70@25: python 3.3 byte-compiled [] Strength = 70@26: python 3.4 byte-compiled [] Strength = 70@27: python 3.5.1- byte-compiled [] Strength = 70@28: python 3.5.2+ byte-compiled [] Strength = 70@29: python 3.6 byte-compiled [] Strength = 70@30: python 3.7 byte-compiled [] Strength = 70@10: Conary changeset data [] Strength = 70@42: Git pack index [] Strength = 70@47: Git index [] Strength = 70@53: Mercurial bundle, [] Strength = 70@72: RIFF (little-endian) data [] Strength = 70@265: RIFF (big-endian) data [] Strength = 70@7: RPM [application/x-rpm] Strength = 70@34: Delta RPM [application/x-rpm] Strength = 70@10: MTZ reflection file [] Strength = 70@30: CCP4 Electron Density Map [] Strength = 70@102: GDSII Stream file [] Strength = 70@6: Sun 'jks' Java Keystore File data [] Strength = 70@6: SE Linux modular policy [] Strength = 70@8: BALANCE NS32000 .o [] Strength = 70@11: BALANCE NS32000 executable (0 @ 0) [] Strength = 70@14: BALANCE NS32000 executable (invalid @ 0) [] Strength = 70@17: BALANCE NS32000 standalone executable [] Strength = 70@26: Sereal data packet [application/sereal] Strength = 70@29: Sereal data packet [application/sereal] Strength = 70@24: IRIS Showcase file [] Strength = 70@26: IRIS Showcase template [] Strength = 70@28: IRIX Parallel Arena [] Strength = 70@34: IRIX core dump [] Strength = 70@38: IRIX 64-bit core dump [] Strength = 70@42: IRIX N32 core dump [] Strength = 70@74: PCP compiled namespace (V.0) [] Strength = 70@78: PCP archive [] Strength = 70@107: PCP Help [] Strength = 70@119: SpeedShop data file [] Strength = 70@122: mdbm file, version 0 (obsolete) [] Strength = 70@123: mdbm file, [] Strength = 70@137: Alias Maya Image File [] Strength = 70@138: Alias Maya Image File [] Strength = 70@12: SVG Scalable Vector Graphics image [image/svg] Strength = 70@32: QDOS executable [] Strength = 70@36: QL plugin-ROM data, [] Strength = 70@12: NetMon capture file [] Strength = 70@25: NetMon capture file [] Strength = 70@69: NetXRay capture file [] Strength = 70@271: pcap capture file, microseconds ts (big-endian) [application/vnd.tcpdump.pcap] Strength = 70@274: pcap capture file, microsecond ts (little-endian) [application/vnd.tcpdump.pcap] Strength = 70@279: pcap capture file, nanosecond ts (big-endian) [application/vnd.tcpdump.pcap] Strength = 70@282: pcap capture file, nanosecond ts (little-endian) [application/vnd.tcpdump.pcap] Strength = 70@289: pcap capture file, microsecond ts, extensions (big-endian) [] Strength = 70@291: pcap capture file, microsecond ts, extensions (little-endian) [] Strength = 70@336: NetStumbler log file [] Strength = 70@342: EtherPeek/AiroPeek/OmniPeek capture file [] Strength = 70@347: Visual Networks traffic capture file [] Strength = 70@357: 5View capture file [] Strength = 70@35: SoftQuad troff Context intermediate for HP LaserJet [] Strength = 70@37: SoftQuad troff Context intermediate for PostScript [] Strength = 70@8: SPEC [] Strength = 70@42: Spectrum .RZX data [] Strength = 70@60: zx-state snapshot [] Strength = 70@43: MySQL ISAM index file [] Strength = 70@45: MySQL ISAM compressed data file [] Strength = 70@47: MySQL MyISAM index file [] Strength = 70@54: MySQL MyISAM compressed data file [] Strength = 70@56: MySQL Maria index file [] Strength = 70@58: MySQL Maria compressed data file [] Strength = 70@63: MySQL replication log, [] Strength = 70@123: SQLite Write-Ahead Log, [] Strength = 70@12: a.out SunOS SPARC demand paged [] Strength = 70@20: a.out SunOS SPARC pure [] Strength = 70@25: a.out SunOS SPARC [] Strength = 70@30: a.out SunOS mc68020 demand paged [] Strength = 70@38: a.out SunOS mc68020 pure [] Strength = 70@43: a.out SunOS mc68020 [] Strength = 70@48: a.out SunOS mc68010 demand paged [] Strength = 70@56: a.out SunOS mc68010 pure [] Strength = 70@61: a.out SunOS mc68010 [] Strength = 70@70: SunOS core file [] Strength = 70@92: SunPC 4.0 Hard Disk [] Strength = 70@141: COBALT boot rom data (Flat boot rom or file system) [] Strength = 70@17: SymbOS driver [] Strength = 70@320: Roland TR-707 Data [] Strength = 70@62: PDCurses screen image [] Strength = 70@108: LyX document text [] Strength = 70@9: timezone data [] Strength = 70@8: Unicode text, UTF-7 [] Strength = 70@9: Unicode text, UTF-7 [] Strength = 70@10: Unicode text, UTF-7 [] Strength = 70@11: Unicode text, UTF-7 [] Strength = 70@12: Unicode text, UTF-8-EBCDIC [] Strength = 70@13: Unicode text, UTF-32, big-endian [] Strength = 70@14: Unicode text, UTF-32, little-endian [] Strength = 70@32: unknown demand paged pure executable [] Strength = 70@34: unknown readable demand paged pure executable [] Strength = 70@7: uterus file [] Strength = 70@18: Ultrix core file [] Strength = 70@28: GNU prof performance data [] Strength = 70@32: Harbour HRB file [] Strength = 70@35: Harbour variable dump file [] Strength = 70@44: ST40 component image format [] Strength = 70@8: a [] Strength = 70@14: a [] Strength = 70@6: VAX single precision APL workspace [] Strength = 70@7: VAX double precision APL workspace [] Strength = 70@13: a.out VAX demand paged (first page unmapped) pure executable [] Strength = 70@205: VMWare3 [] Strength = 70@213: VMware4 disk image [] Strength = 70@214: VMware4 disk image [] Strength = 70@286: QEMU suspend to disk image [] Strength = 70@290: QEMU QED Image [] Strength = 70@296: VirtualBox Disk Image [] Strength = 70@306: Bochs Sparse disk image [] Strength = 70@7: Virtutech CRAFF [] Strength = 70@15: VMS VAX executable [] Strength = 70@6: VMware nvram [] Strength = 70@25: Ogg data [] Strength = 70@13: VXL data file, [] Strength = 70@13: WebAssembly (wasm) binary module [] Strength = 70@20: MS Outlook Express DBX file [] Strength = 70@137: MS Windows 3.1 group files [] Strength = 70@279: MS Windows help Full Text Search index [application/x-winhelp-fts] Strength = 70@342: Microsoft Outlook email folder [] Strength = 70@361: MS Windows registry file, NT/2000 or above [] Strength = 70@362: MS Windows 95/98/ME registry file [] Strength = 70@6: CRDA wireless regulatory database file [] Strength = 70@204: Ted Neslson's CosmicBook hypertext file [] Strength = 70@206: AmigaWriter file [] Strength = 70@211: ChiWriter file [] Strength = 70@221: Adobe InDesign [] Strength = 70@262: gfxboot compiled html help file [] Strength = 70@9: PHP WSDL cache, [] Strength = 70@13: VCDIFF binary diff [] Strength = 70@14: core file (Xenix) [] Strength = 70@73: b.out [] Strength = 70@7: xo65 object, [] Strength = 70@13: xo65 library, [] Strength = 70@20: Jaleo XFS file [] Strength = 70@32: Xcursor data [image/x-xcursor] Strength = 70@9: object file (z8000 a.out) [] Strength = 70@10: pure object file (z8000 a.out) [] Strength = 70@11: separate object file (z8000 a.out) [] Strength = 70@12: overlay object file (z8000 a.out) [] Strength = 61@24: Apache Hadoop Sequence file version %d [] Strength = 61@465: MS Compress archive data, KWAJ variant [application/x-ms-compress-kwaj] Strength = 61@563: MS Compress archive data, QBasic variant [application/x-ms-compress-sz] Strength = 61@865: General Digital Music. [] Strength = 61@883: Hively Tracker Song [] Strength = 61@888: MOdule with MP3 [] Strength = 61@900: by Bastian Spiegel(twice/lego)" [] Strength = 61@911: Farandole Tracker Song [] Strength = 61@59: RAP 1.%d Batch (TD.32, Returned Account Procedure), [] Strength = 61@65: RAP Acknowledgement (TD.32, Returned Account Procedure) [] Strength = 61@379: BWC compressed data [] Strength = 61@54: LCOV coverage tracefile [] Strength = 61@43: Cups Raster version 1, Big Endian [] Strength = 61@52: Cups Raster version 1, Little Endian [] Strength = 61@248: HP 38 [] Strength = 61@267: HP 38 [] Strength = 61@124: JPEG-XR [image/jxr] Strength = 61@106: MSX G9B image, depth=%d [] Strength = 61@139: Oak Technologies printer stream [] Strength = 61@28: Spectrum .TAP data "%-10.10s" [] Strength = 61@232: Just System Word Processor Ichitaro v4 [application/x-ichitaro4] Strength = 61@237: Just System Word Processor Ichitaro v5 [application/x-ichitaro5] Strength = 61@241: Just System Word Processor Ichitaro v6 [application/x-ichitaro6] Strength = 61@10: Yanagisawa PIC image file, [] Strength = 60@64: LZX compressed archive (Amiga) [] Strength = 60@973: Bink Video [] Strength = 60@1048: RAD Game Tools Smacker Multimedia [] Strength = 60@7: Apache Avro [] Strength = 60@12: Apache ORC [] Strength = 60@18: Apache Hive RC file [] Strength = 60@7: Binary II (apple ][) data [] Strength = 60@383: SAR archive data [] Strength = 60@390: MAR archive data [] Strength = 60@398: Quantum archive data [] Strength = 60@411: AMGC archive data [] Strength = 60@419: PSA archive data [] Strength = 60@443: ESP archive data [] Strength = 60@449: UFA archive data [] Strength = 60@583: UHarc archive data [] Strength = 60@585: ABComp archive data [] Strength = 60@588: CMP archive data [] Strength = 60@590: Splint archive data [] Strength = 60@594: Gather archive data [] Strength = 60@596: BOA archive data [] Strength = 60@611: PRO-PACK archive data [] Strength = 60@613: 777 archive data [] Strength = 60@617: HPA archive data [] Strength = 60@630: Par archive data [] Strength = 60@636: NaShrink archive data [] Strength = 60@641: Disintegrator archive data [] Strength = 60@643: ASD archive data [] Strength = 60@647: TOP4 archive data [] Strength = 60@664: AKT archive data [] Strength = 60@670: SemOne archive data [] Strength = 60@674: FIZ archive data [] Strength = 60@690: SBC archive data [] Strength = 60@692: Ybs archive data [] Strength = 60@694: DitPack archive data [] Strength = 60@700: VSARC archive data [] Strength = 60@702: PDZ archive data [] Strength = 60@714: UHBC archive data [] Strength = 60@718: WWPack archive data [] Strength = 60@723: BSN archive data [] Strength = 60@724: BSN archive data [] Strength = 60@725: BSN archive data [] Strength = 60@743: XPA [] Strength = 60@785: ZZip archive data [] Strength = 60@788: PAQ archive data [] Strength = 60@1004: PUT archive data [] Strength = 60@1477: ZPAQ stream [] Strength = 60@1536: SeqBox, [] Strength = 60@96: SoundBlaster instrument data [audio/x-unknown] Strength = 60@231: TOC sound file [] Strength = 60@296: Audio file with ID3 version 2 [] Strength = 60@393: MED_Song [] Strength = 60@398: AHX version [] Strength = 60@441: AMF Module [] Strength = 60@558: AMUSIC Adlib Tracker [] Strength = 60@560: EdLib [] Strength = 60@573: DFM Song [] Strength = 60@621: Musepack audio (MP+) [audio/x-musepack] Strength = 60@877: Multitracker [] Strength = 60@996: Portable Sound Format [audio/x-psf] Strength = 60@58: Biosig/GDF: General data format for biosignals [biosig/gdf] Strength = 60@9: Chiasmus key [] Strength = 60@21: Microstation [] Strength = 60@6: Concise Binary Object Representation (CBOR) container [application/cbor] Strength = 60@21: Message Sequence Chart (chart) [] Strength = 60@144: bzip2 compressed data [application/x-bzip2] Strength = 60@150: bzip compressed data [application/x-bzip] Strength = 60@505: CPE executable [] Strength = 60@592: Nintendo Gameboy Music/Audio Data [] Strength = 60@522: ICE authority data [] Strength = 60@46: ddis/ddif [] Strength = 60@47: ddis/dots archive [] Strength = 60@48: ddis/dtif table data [] Strength = 60@49: LN03 output [] Strength = 60@2382: floppy image data (TeleDisk, compressed) [] Strength = 60@2383: floppy image data (TeleDisk) [] Strength = 60@2385: floppy image data (CopyQM, [] Strength = 60@10: libfprint fingerprint data V1 [] Strength = 60@14: libfprint fingerprint data V2 [] Strength = 60@114: FIGlet font [] Strength = 60@116: FIGlet controlfile [] Strength = 60@5: FuseCompress(ed) data [] Strength = 60@42: LADS Caris Ascii Format (CAF) bathymetric lidar [] Strength = 60@45: LADS Caris Binary Format (CBF) bathymetric lidar waveform data [] Strength = 60@96: ECMA-363, Universal 3D [] Strength = 60@8: Gringotts data file [] Strength = 60@470: PBF image (deflate compression) [image/x-unknown] Strength = 60@25: Linux/i386 object file [] Strength = 60@270: LVM1 (Linux Logical Volume Manager), version 1 [] Strength = 60@273: LVM1 (Linux Logical Volume Manager), version 2 [] Strength = 60@20: StuffIt Deluxe Segment (data) [] Strength = 60@334: SAS [] Strength = 60@341: SAS 7+ [] Strength = 60@64: MAthematica .ml file [] Strength = 60@6: mcrypt 2.5 encrypted data, [] Strength = 60@11: mcrypt 2.2 encrypted data, [] Strength = 60@356: FreeDOS KEYBoard Layout collection [] Strength = 60@367: FreeDOS KEYBoard Layout file [] Strength = 60@1397: Microsoft Word Document [application/msword] Strength = 60@1433: Mallard BASIC program data (v1.11) [] Strength = 60@1434: Mallard BASIC program data (v1.29+) [] Strength = 60@1435: Mallard BASIC protected program data (v1.11) [] Strength = 60@1436: Mallard BASIC protected program data (v1.29+) [] Strength = 60@10: MSX Gigamix MGSDRV3 music file, [] Strength = 60@49: MSX Music Player K-kaz song [] Strength = 60@8: Progressive Graphics image data, [image/x-pgf] Strength = 60@129: PGP RSA encrypted session key - [] Strength = 60@19: PostScript document text [application/postscript] Strength = 60@88: HP PCL printer data [] Strength = 60@22: SCCS archive data [] Strength = 60@75: PCP compiled namespace [] Strength = 60@115: PCP memory mapped values [] Strength = 60@9: QL disk dump data, [] Strength = 60@22: Smile binary data [] Strength = 60@230: Virtual TI skin [] Strength = 60@15: Unicode text, SCSU (Standard Compression Scheme for Unicode) [] Strength = 60@20: a [] Strength = 60@26: script executable [] Strength = 60@8: Compiled XKB Keymap: lsb, [] Strength = 60@11: Compiled XKB Keymap: msb, [] Strength = 56@28: [] Strength = 55@71: new-fs dump file (little endian), [] Strength = 51@41: Infocom (Z-machine %d [] Strength = 51@450: MPEG ADTS, layer III, v1, 32 kbps [audio/mpeg] Strength = 51@801: FLI animation, 320x200x8 [video/x-fli] Strength = 51@812: FLC animation [video/x-flc] Strength = 51@372: Apple Driver Map [application/x-apple-diskimage] Strength = 51@440: TTComp archive, binary, 4K dictionary [] Strength = 51@738: Xpack DiskImage archive data [] Strength = 51@776: Dzip archive data [application/x-dzip] Strength = 51@986: Lossless audio version 0.3 [] Strength = 51@13: Blocked GNU Zip Format (BGZF; gzip compatible) [] Strength = 51@114: Kompas drawing 12.0 SP1 [] Strength = 51@154: 3D Studio model [image/x-3ds] Strength = 51@41: Monu-Cad Drawing, Component or Font [] Strength = 51@575: Lynx homebrew cartridge [application/x-atari-lynx-rom] Strength = 51@11: COFF format alpha pure [] Strength = 51@17: Dyalog APL [] Strength = 51@12: configuration of Tasmota firmware (ESP8266) [application/x-tasmota-dmp] Strength = 51@193: Sun disk label [] Strength = 51@1308: GRand Unified Bootloader [] Strength = 51@51: [] Strength = 51@34: Printer Font Metrics [application/x-font-pfm] Strength = 51@138: GPG symmetrically encrypted data (3DES cipher) [] Strength = 51@36: GPT partition table [] Strength = 51@28: AIX core file [] Strength = 51@576: PC bitmap, OS/2 1.x format [image/x-ms-bmp] Strength = 51@872: [] Strength = 51@1615: Vision Research CINE Video, [] Strength = 51@41: [] Strength = 51@46: [] Strength = 51@48: [] Strength = 51@119: [] Strength = 51@37: Emacs v18 byte-compiled Lisp data [application/x-elc] Strength = 51@389: Macintosh HFS data [application/x-apple-diskimage] Strength = 51@38: [] Strength = 51@17: MARC21 Bibliographic [application/marc] Strength = 51@35: raw G3 (Group 3) FAX, byte-padded [image/g3fax] Strength = 51@46: raw G3 (Group 3) FAX [image/g3fax] Strength = 51@80: Brooktrout 301 fax image, [] Strength = 51@54: MS-DOS executable [application/x-dosexec] Strength = 51@563: FREE-DOS executable (COM), UPX compressed [application/x-dosexec] Strength = 51@594: COM executable for DOS [application/x-dosexec] Strength = 51@599: COM executable for DOS [application/x-dosexec] Strength = 51@66: MSX OPX Music file [] Strength = 51@136: MSX BIOS+BASIC [] Strength = 51@176: MSX2/2+/TR SubROM [] Strength = 51@190: MSX ROM [] Strength = 51@226: MSX ROM [] Strength = 51@247: MSX ROM with nonstandard page order [] Strength = 51@255: MSX ROM with nonstandard page order [] Strength = 51@263: MSX MegaROM with nonstandard page order [] Strength = 51@303: Konami King's Valley-2 custom stage, title: "%-8.8s" [] Strength = 51@64: Yanagisawa Pi 16 color picture, [] Strength = 51@19: PDP-11 UNIX/RT ldp [] Strength = 51@31: Perl script text executable [text/x-perl] Strength = 51@26: Sendmail frozen configuration [] Strength = 51@40: SYMMETRY i386 standalone executable [] Strength = 51@17: Compiled terminfo entry "%-s" [application/x-terminfo] Strength = 51@30: Compiled 32-bit terminfo entry "%-s" [application/x-terminfo2] Strength = 51@409: [] Strength = 51@18: Xilinx BIT data [] Strength = 50@7: COFF DSP21k [] Strength = 50@13: ALAN game data [] Strength = 50@13: 0420 Alliant virtual executable [] Strength = 50@16: 0421 Alliant compact executable [] Strength = 50@13: Amiga Workbench [] Strength = 50@43: AmigaOS bitmap font [] Strength = 50@44: AmigaOS outline font [] Strength = 50@33: JPEG 2000 image [image/jp2] Strength = 50@496: MPEG ADTS, layer II, v1 [audio/mpeg] Strength = 50@571: MPEG ADTS, layer III, v2 [audio/mpeg] Strength = 50@606: MPEG ADTS, layer II, v2 [audio/mpeg] Strength = 50@641: MPEG ADTS, layer I, v2 [audio/mpeg] Strength = 50@676: MPEG ADTS, layer III, v2.5 [audio/mpeg] Strength = 50@738: MPEG ADTS, AAC [audio/x-hx-aac-adts] Strength = 50@775: MPEG-4 LOAS [audio/x-mp4a-latm] Strength = 50@8: Squeezed (apple ][) data [] Strength = 50@166: cpio archive [application/x-cpio] Strength = 50@168: byte-swapped cpio archive [application/x-cpio] Strength = 50@190: very old 16-bit-int little-endian archive [] Strength = 50@191: very old 16-bit-int big-endian archive [] Strength = 50@195: old 16-bit-int little-endian archive [] Strength = 50@197: old 16-bit-int big-endian archive [] Strength = 50@402: QuArk archive data [] Strength = 50@404: YAC archive data [] Strength = 50@406: X1 archive data [] Strength = 50@427: NSQ archive data [] Strength = 50@447: Sky archive data [] Strength = 50@619: Arhangel archive data [] Strength = 50@632: HIT archive data [] Strength = 50@659: Logitech Compress archive data [] Strength = 50@708: PPMN archive data [] Strength = 50@727: AIN archive data [] Strength = 50@728: AIN archive data [] Strength = 50@796: ARJ archive data [application/x-arj] Strength = 50@815: ARJ archive data [] Strength = 50@1263: PRCS packaged project [] Strength = 50@1295: Atari MSA archive data [] Strength = 50@21: WE32000 COFF [] Strength = 50@33: WE32000 COFF executable (TV) [] Strength = 50@990: Sony PlayStation Audio [] Strength = 50@14: VAX-order 68K Blit (standalone) executable [] Strength = 50@16: VAX-order2 68k Blit mpx/mux executable [] Strength = 50@17: VAX-order 68k Blit mpx/mux executable [] Strength = 50@25: C64 PCLink Image [] Strength = 50@146: Bentley/Intergraph MicroStation [] Strength = 50@10: Clarion Developer (v2 and above) data file [] Strength = 50@21: Clarion Developer (v2 and above) memo data [] Strength = 50@27: Clarion Developer (v2 and above) help data [] Strength = 50@31: CLIPPER COFF executable (VAX #) [] Strength = 50@39: CLIPPER COFF executable [] Strength = 50@12: compress'd data [application/x-compress] Strength = 50@122: packed data [application/octet-stream] Strength = 50@128: old packed data [application/octet-stream] Strength = 50@134: compacted data [application/octet-stream] Strength = 50@138: compacted data [application/octet-stream] Strength = 50@140: huf output [application/octet-stream] Strength = 50@161: squeezed data, [] Strength = 50@163: crunched data, [] Strength = 50@165: LZH compressed data, [] Strength = 50@169: frozen file 2.1 [] Strength = 50@170: frozen file 1.0 (or gzip 0.5) [] Strength = 50@173: SCO compress -H (LZH) data [] Strength = 50@231: Quasijarus strong compressed data [] Strength = 50@41: Alpha compressed COFF [] Strength = 50@42: Alpha u-code object [] Strength = 50@56: locale data table [] Strength = 50@9: ATSC A/52 aka AC-3 aka Dolby Digital stream, [audio/vnd.dolby.dd-raw] Strength = 50@86: old-fs dump file (16-bit, assuming PDP-11 endianness), [] Strength = 50@61: Dyalog APL transfer [] Strength = 50@9: Encore [] Strength = 50@18: Encore unsupported executable [] Strength = 50@1714: Linux [] Strength = 50@2146: Linux old jffs2 filesystem data little endian [] Strength = 50@2147: Linux jffs2 filesystem data little endian [] Strength = 50@2391: floppy image data (IBM SaveDskF, old) [] Strength = 50@2392: floppy image data (IBM SaveDskF) [] Strength = 50@2393: floppy image data (IBM SaveDskF, compressed) [] Strength = 50@7: Berkeley vfont data [] Strength = 50@8: byte-swapped Berkeley vfont data [] Strength = 50@8: fsav macro virus signatures [] Strength = 50@12: RDI Acoustic Doppler Current Profiler (ADCP) [] Strength = 50@57: GeoSwath RDF [] Strength = 50@122: GPG encrypted data [text/PGP] Strength = 50@42: Apollo m68k COFF executable [] Strength = 50@45: apollo a88k COFF executable [] Strength = 50@284: hp200 (68010) BSD [] Strength = 50@288: hp300 (68020+68881) BSD [] Strength = 50@21: 370 XA sysV executable [] Strength = 50@25: 370 XA sysV pure executable [] Strength = 50@29: 370 sysV pure executable [] Strength = 50@31: 370 XA sysV pure executable [] Strength = 50@33: 370 sysV executable [] Strength = 50@35: 370 XA sysV executable [] Strength = 50@37: SVR2 executable (Amdahl-UTS) [] Strength = 50@40: SVR2 pure executable (Amdahl-UTS) [] Strength = 50@43: SVR2 pure executable (USS/370) [] Strength = 50@46: SVR2 executable (USS/370) [] Strength = 50@6: executable (RISC System/6000 V3.1) or obj module [] Strength = 50@13: shared library [] Strength = 50@14: ctab data [] Strength = 50@15: structured file [] Strength = 50@23: 64-bit XCOFF executable or object module [] Strength = 50@218: Netpbm PAM image file [image/x-portable-pixmap] Strength = 50@222: Solitaire Image Recorder format [] Strength = 50@528: MGR bitmap, modern format, 8-bit aligned [] Strength = 50@529: MGR bitmap, old format, 1-bit deep, 16-bit aligned [] Strength = 50@530: MGR bitmap, old format, 1-bit deep, 32-bit aligned [] Strength = 50@531: MGR bitmap, modern format, squeezed [] Strength = 50@547: Award BIOS Logo, 136 x 84 [image/x-award-bioslogo] Strength = 50@549: Award BIOS Logo, 136 x 126 [image/x-award-bioslogo] Strength = 50@617: RLE image data, [] Strength = 50@658: SGI image data [] Strength = 50@706: PEX Binary Archive [] Strength = 50@764: Atari ATR image [] Strength = 50@1393: BS image, [] Strength = 50@1786: Zebra Metafile graphic [] Strength = 50@17: basic-16 executable [] Strength = 50@20: basic-16 executable (TV) [] Strength = 50@23: x86 executable [] Strength = 50@25: x86 executable (TV) [] Strength = 50@27: iAPX 286 executable small model (COFF) [] Strength = 50@30: iAPX 286 executable large model (COFF) [] Strength = 50@55: BIOS (ia32) ROM Ext. [application/octet-stream] Strength = 50@12: little endian ispell [] Strength = 50@34: big endian ispell [] Strength = 50@10: Java serialization data [] Strength = 50@8: lif file [] Strength = 50@60: Linux/i386 PC Screen Font v1 data, [] Strength = 50@372: Macintosh MFS data [] Strength = 50@417: Macintosh HFS Extended [] Strength = 50@7: MIPSEB ECOFF executable [] Strength = 50@16: MIPSEL-BE ECOFF executable [] Strength = 50@25: MIPSEB-LE ECOFF executable [] Strength = 50@34: MIPSEL ECOFF executable [] Strength = 50@45: MIPSEB MIPS-II ECOFF executable [] Strength = 50@54: MIPSEL-BE MIPS-II ECOFF executable [] Strength = 50@63: MIPSEB-LE MIPS-II ECOFF executable [] Strength = 50@72: MIPSEL MIPS-II ECOFF executable [] Strength = 50@83: MIPSEB MIPS-III ECOFF executable [] Strength = 50@92: MIPSEL-BE MIPS-III ECOFF executable [] Strength = 50@101: MIPSEB-LE MIPS-III ECOFF executable [] Strength = 50@110: MIPSEL MIPS-III ECOFF executable [] Strength = 50@119: MIPSEB Ucode [] Strength = 50@120: MIPSEL-BE Ucode [] Strength = 50@10: ID tags data [] Strength = 50@8: mc68k COFF [] Strength = 50@17: mc68k executable (shared) [] Strength = 50@19: mc68k executable (shared demand paged) [] Strength = 50@24: 68K BCS executable [] Strength = 50@30: 88K BCS executable [] Strength = 50@33: Motorola S-Record; binary data in text format [] Strength = 50@54: Atari 68xxx executable, [] Strength = 50@70: Atari 68xxx CPX file [] Strength = 50@37: MS Windows COFF MIPS R4000 object file [] Strength = 50@39: MS Windows COFF Alpha object file [] Strength = 50@41: MS Windows COFF Motorola 68000 object file [] Strength = 50@43: MS Windows COFF PowerPC object file [] Strength = 50@45: MS Windows COFF PA-RISC object file [] Strength = 50@581: COM executable for DOS [application/x-dosexec] Strength = 50@585: COM executable for DOS [application/x-dosexec] Strength = 50@589: COM executable for DOS [application/x-dosexec] Strength = 50@603: COM executable for DOS [application/x-dosexec] Strength = 50@607: COM executable for MS-DOS [application/x-dosexec] Strength = 50@611: COM executable for MS-DOS [application/x-dosexec] Strength = 50@615: COM executable for MS-DOS [application/x-dosexec] Strength = 50@619: COM executable for DOS [application/x-dosexec] Strength = 50@636: MS-DOS executable (built-in) [] Strength = 50@10: Tower/XP rel 2 object [] Strength = 50@15: Tower/XP rel 2 object [] Strength = 50@20: Tower/XP rel 3 object [] Strength = 50@25: Tower/XP rel 3 object [] Strength = 50@30: Tower32/600/400 68020 object [] Strength = 50@35: Tower32/800 68020 [] Strength = 50@43: Tower32/800 68010 [] Strength = 50@31: OS9/6809 module: [] Strength = 50@53: OS9/68K module: [] Strength = 50@10: i386 COFF object [] Strength = 50@8: PARIX [] Strength = 50@8: "compact bitmap" format (Poskanzer) [] Strength = 50@11: PDP-11 executable [] Strength = 50@22: PDP-11 old overlay [] Strength = 50@24: PDP-11 pure executable [] Strength = 50@28: PDP-11 separate I&D executable [] Strength = 50@32: PDP-11 kernel overlay [] Strength = 50@35: PDP-11 demand-paged pure executable [] Strength = 50@38: PDP-11 overlaid pure executable [] Strength = 50@41: PDP-11 overlaid separate executable [] Strength = 50@48: PGP key security ring [application/x-pgp-keyring] Strength = 50@50: PGP key security ring [application/x-pgp-keyring] Strength = 50@52: PGP encrypted data [text/PGP] Strength = 50@8: mumps avl global [] Strength = 50@12: mumps blt global [] Strength = 50@8: PostScript document text [application/postscript] Strength = 50@110: interLaced eXtensible Trace (LXT) file [] Strength = 50@24: SYMMETRY i386 .o [] Strength = 50@27: SYMMETRY i386 executable (0 @ 0) [] Strength = 50@30: SYMMETRY i386 executable (invalid @ 0) [] Strength = 50@16: disk quotas file [] Strength = 50@18: IRIS Showcase file [] Strength = 50@21: IRIS Showcase template [] Strength = 50@21: SHARC COFF binary [] Strength = 50@28: QDOS object [] Strength = 50@318: Novell LANalyzer capture file [] Strength = 50@319: Novell LANalyzer capture file [] Strength = 50@16: Compiled PSI (v1) data [] Strength = 50@17: Compiled PSI (v2) data [] Strength = 50@20: SoftQuad DESC or font file binary [] Strength = 50@26: SoftQuad troff Context intermediate [] Strength = 50@11: MySQL table definition file [] Strength = 50@9: SysEx File - [] Strength = 50@39: SVr2 curses screen image, big-endian [] Strength = 50@40: SVr3 curses screen image, big-endian [] Strength = 50@41: SVr4 curses screen image, big-endian [] Strength = 50@43: SVr2 curses screen image, little-endian [] Strength = 50@44: SVr3 curses screen image, little-endian [] Strength = 50@45: SVr4 curses screen image, little-endian [] Strength = 50@13: TeX DVI file [application/x-dvi] Strength = 50@16: TeX generic font data [] Strength = 50@17: TeX packed font data [] Strength = 50@19: TeX virtual font data [] Strength = 50@26: TeX font metric data [application/x-tex-tfm] Strength = 50@29: TeX font metric data [application/x-tex-tfm] Strength = 50@38: very old (C/A/T) troff output data [] Strength = 50@10: Perkin-Elmer executable [] Strength = 50@12: amd 29k coff noprebar executable [] Strength = 50@13: amd 29k coff prebar executable [] Strength = 50@14: amd 29k coff archive [] Strength = 50@16: unicos (cray) executable [] Strength = 50@22: VAX COFF executable [] Strength = 50@25: VAX COFF pure executable [] Strength = 50@6: VISX image file [] Strength = 50@35: x.out [] Strength = 50@38: Microsoft a.out [] Strength = 50@66: old Microsoft 8086 x.out [] Strength = 50@92: XENIX 8086 relocatable or 80286 small model [] Strength = 48@53: SVG XML document [image/svg+xml] Strength = 46@544: Windows Precompiled iNF [application/x-pnf] Strength = 41@158: AppleWorks Word Processor [application/x-appleworks3] Strength = 41@31: TAP 3.%d Batch (TD.57, Transferred Account) [] Strength = 41@39: TAP 3.%d Notification (TD.57, Transferred Account) [] Strength = 41@47: NRT 2.%d (TD.35, Near Real Time Roaming Data Exchange) [] Strength = 41@949: Nintendo amiibo NFC dump - amiibo ID: %08X- [] Strength = 41@185: DBF [] Strength = 41@13: eml://ecoinformatics.org/%s [] Strength = 41@40: https://www.openarchives.org/ore/terms [application/rdf+xml] Strength = 41@30: DER Encoded Certificate request [] Strength = 41@37: DER Encoded Key Pair, 512 bits [] Strength = 41@42: DER Encoded Key Pair, 1024 bits [] Strength = 41@47: DER Encoded Key Pair, 2048 bits [] Strength = 41@52: DER Encoded Key Pair, 4096 bits [] Strength = 41@57: DER Encoded Key Pair, 8192 bits [] Strength = 41@62: DER Encoded Key Pair, 16k bits [] Strength = 41@67: DER Encoded Key Pair, 32k bits [] Strength = 41@72: DER Encoded Certificate, 512 bits [] Strength = 41@20: [] Strength = 41@28: [] Strength = 41@728: XWD X Window Dump image data [image/x-xwindowdump] Strength = 41@96: [] Strength = 41@325: TomTom activity file, v7 [] Strength = 41@20: Micro Focus Index File (IDX) [application/octet-stream] Strength = 41@475: DOS executable (COM, 0x8C-variant) [application/x-dosexec] Strength = 41@511: [] Strength = 41@524: [] Strength = 41@533: COM executable (32-bit COMBOOT [application/x-c32-comboot-syslinux-exec] Strength = 41@1479: DOS 2.0-3.2 backed up [] Strength = 41@88: MSX SC2/GRP raw image [] Strength = 41@100: MSX Graph Saurus compressed image [] Strength = 41@278: MSX-BASIC program [] Strength = 41@287: MSX Mega-Assembler source [] Strength = 41@24: PGP key public ring (v%u) [application/pgp-keys] Strength = 41@535: PGP Secret Sub-key [] Strength = 41@20: Sendmail frozen configuration [] Strength = 41@39: Soundtrakker 128 ST2 music, [] Strength = 41@16: [] Strength = 41@412: [] Strength = 41@415: [] Strength = 41@28: 8086 relocatable (Microsoft) [application/x-object] Strength = 40@175: AutoCAD Drawing Exchange Format [application/x-dxf] Strength = 40@623: COM executable for MS-DOS [application/x-dosexec] Strength = 40@626: COM executable for DOS [application/x-dosexec] Strength = 40@15: IBM OS/400 save file data [] Strength = 40@255: PGP symmetric key encrypted data - [] Strength = 40@520: PGP Secret Key - [] Strength = 40@522: PGP Secret Sub-key - [] Strength = 40@62: GLF_BINARY_LSB_FIRST [] Strength = 40@64: GLF_BINARY_MSB_FIRST [] Strength = 40@68: GLS_BINARY_LSB_FIRST [] Strength = 40@70: GLS_BINARY_MSB_FIRST [] Strength = 38@13: Cracklib password index, big endian ("64-bit") [] Strength = 35@42: Linux/i386 core file [] Strength = 26@1770: Minix filesystem, V1, 14 char names, %d zones [] Strength = 26@1775: Minix filesystem, V1 (big endian), %d zones [] Strength = 26@1780: Minix filesystem, V1, 30 char names, %d zones [] Strength = 26@1785: Minix filesystem, V1, 30 char names (big endian), %d zones [] Strength = 21@1032: Bio-Rad .PIC Image File [] Strength = 21@491: [] Strength = 21@1451: DOS 2.0 backup id file, sequence %d [] Strength = 18@42: a [] Strength = 17@34: a [] Strength = 11@918: Atari 7800 ROM image [application/x-atari-7800-rom] Strength = 11@383: [] Strength = 11@608: Panorama database [] Strength = 11@31: (Lepton 3.x), [] Strength = 11@37: (Lepton 2.x), [] Strength = 2@374: zlib compressed data [application/zlib] Text patterns: Strength = 250@27: Tenex C shell script text executable [text/x-shellscript] Strength = 250@46: new awk script text executable [text/x-nawk] Strength = 250@52: GNU awk script text executable [text/x-gawk] Strength = 250@77: Bourne-Again shell script text executable [text/x-shellscript] Strength = 240@36: Paul Falstad's zsh script text executable [text/x-shellscript] Strength = 240@38: Neil Brown's ash script text executable [text/x-shellscript] Strength = 230@40: Neil Brown's ae script text executable [text/x-shellscript] Strength = 230@81: Bourne-Again shell script text executable [text/x-shellscript] Strength = 220@6: KDE desktop entry [application/x-kdelnk] Strength = 210@25: Tenex C shell script text executable [text/x-shellscript] Strength = 210@73: Bourne-Again shell script text executable [text/x-shellscript] Strength = 200@8: KDE config file [application/x-kdelnk] Strength = 190@23: Tenex C shell script text executable [text/x-shellscript] Strength = 190@44: new awk script text executable [text/x-nawk] Strength = 190@50: GNU awk script text executable [text/x-gawk] Strength = 190@69: Bourne-Again shell script text executable [text/x-shellscript] Strength = 185@103: XML [text/xml] Strength = 185@106: XML [text/xml] Strength = 181@30: XHTML document text [] Strength = 181@34: XHTML document text [] Strength = 181@38: broken XHTML document text [] Strength = 180@34: Paul Falstad's zsh script text executable [text/x-shellscript] Strength = 180@57: awk script text executable [text/x-awk] Strength = 171@7: %s [] Strength = 171@18: XML Sitemap document text [application/xml-sitemap] Strength = 170@7: old news text [message/rfc822] Strength = 161@9: %s [] Strength = 160@7: GIMP gradient data [] Strength = 160@1208: Polar Monitor Bitmap text [image/x-polar-monitor-bitmap] Strength = 160@17: SMTP mail text [message/rfc822] Strength = 160@32: MIME entity text [] Strength = 150@21: Tenex C shell script text executable [text/x-shellscript] Strength = 150@42: new awk script text executable [text/x-nawk] Strength = 150@48: GNU awk script text executable [text/x-gawk] Strength = 150@65: Bourne-Again shell script text executable [text/x-shellscript] Strength = 150@11: GIMP palette data [] Strength = 150@19: SMTP mail text [message/rfc822] Strength = 150@6: cvs password text file [] Strength = 150@131: Alias Maya Ascii File, [] Strength = 140@12: C shell script text executable [text/x-shellscript] Strength = 140@16: Korn shell script text executable [text/x-shellscript] Strength = 140@32: Paul Falstad's zsh script text executable [text/x-shellscript] Strength = 140@55: awk script text executable [text/x-awk] Strength = 137@176: GNU gettext message catalogue text [text/x-po] Strength = 130@7: POSIX shell script text executable [text/x-shellscript] Strength = 130@62: Plan 9 rc shell script text executable [] Strength = 130@13: mail forwarding text [message/rfc822] Strength = 129@27: unified diff output text [text/x-diff] Strength = 120@11: mailed, batched news text [message/rfc822] Strength = 120@30: RFC 822 mail text [message/rfc822] Strength = 110@9: batched news text [message/rfc822] Strength = 106@179: , bitmap [image/x-portable-bitmap] Strength = 106@186: , greymap [image/x-portable-greymap] Strength = 106@193: , pixmap [image/x-portable-pixmap] Strength = 100@6: magic text file for file(1) cmd [] Strength = 100@15: mail piping text [message/rfc822] Strength = 100@27: saved news text [message/news] Strength = 100@27: PDF document [application/pdf] Strength = 90@10: xmcd database file for kscd [text/x-xmcd] Strength = 81@11: Google KML document [application/vnd.google-earth.kml+xml] Strength = 80@21: news text [message/news] Strength = 80@23: news text [message/news] Strength = 80@25: news or mail text [message/rfc822] Strength = 80@29: Emacs RMAIL text [] Strength = 80@33: Ruby script text [text/x-ruby] Strength = 78@37: Perl5 module source text [] Strength = 76@42: Perl5 module source text [] Strength = 71@63: C++ source text [text/x-c++] Strength = 70@58: C++ source text [text/x-c++] Strength = 70@88: C++ source text [text/x-c++] Strength = 70@86: PHP script text [text/x-php] Strength = 70@5: a [] Strength = 70@11: a [] Strength = 69@67: C++ source text [text/x-c++] Strength = 69@36: Python script text executable [text/x-python] Strength = 68@71: C++ source text [text/x-c++] Strength = 68@84: C++ source text [text/x-c++] Strength = 68@28: Ruby script text [text/x-ruby] Strength = 67@80: C++ source text [text/x-c++] Strength = 67@42: Python script text executable [text/x-python] Strength = 67@12: Ruby script text executable [text/x-ruby] Strength = 66@39: Python script text executable [text/x-python] Strength = 65@18: Ruby script text executable [text/x-ruby] Strength = 65@128: ConTeXt document text [] Strength = 64@15: Ruby script text executable [text/x-ruby] Strength = 63@94: Objective-C source text [text/x-objective-c] Strength = 63@33: Python script text executable [text/x-python] Strength = 63@116: ConTeXt document text [] Strength = 63@126: ConTeXt document text [] Strength = 62@9: Public Suffix List data [] Strength = 62@52: LaTeX document text [text/x-tex] Strength = 62@136: ConTeXt document text [] Strength = 61@93: PHP script text executable [text/x-php] Strength = 61@24: Perl script text [text/x-perl] Strength = 61@9: Ruby script text executable [text/x-ruby] Strength = 61@102: BibTeX standard bibliography style text file [] Strength = 61@120: ConTeXt document text [] Strength = 61@138: ConTeXt document text [] Strength = 61@24: bencoded News text [] Strength = 60@14: Perl script text [text/x-perl] Strength = 60@22: Perl script text [text/x-perl] Strength = 60@9: Python script text executable [] Strength = 60@38: Ruby script text [text/x-ruby] Strength = 60@130: ConTeXt document text [] Strength = 60@17: a [] Strength = 60@23: script text executable [] Strength = 59@58: LaTeX 2e document text [text/x-tex] Strength = 59@134: ConTeXt document text [] Strength = 59@28: BinHex binary text [] Strength = 58@24: libtool library file [] Strength = 58@55: Python script text executable [text/x-python] Strength = 58@13: Qt C-code resource file [] Strength = 58@4: RFC1421 Security Certificate text [] Strength = 58@64: LaTeX table of contents [text/x-tex] Strength = 58@112: ConTeXt document text [] Strength = 58@114: ConTeXt document text [] Strength = 58@122: ConTeXt document text [] Strength = 58@124: ConTeXt document text [] Strength = 57@29: libtool object file [] Strength = 57@61: Python script text executable [] Strength = 57@133: Netscape cookie text [] Strength = 56@92: Python script text executable [text/x-python] Strength = 56@5: RFC1421 Security Certificate Signing Request text [] Strength = 56@46: LaTeX document text [text/x-tex] Strength = 56@55: LaTeX document text [text/x-tex] Strength = 56@132: ConTeXt document text [] Strength = 55@96: PHP script text executable [text/x-php] Strength = 55@49: LaTeX document text [text/x-tex] Strength = 54@76: C++ source text [text/x-c++] Strength = 54@9: M4 macro processor script text [text/x-m4] Strength = 54@12: Perl script text [text/x-perl] Strength = 54@20: Perl script text [text/x-perl] Strength = 54@84: Python script text executable [text/x-python] Strength = 54@99: Python script text executable [text/x-python] Strength = 54@100: BibTeX style text file (with full header) [] Strength = 53@12: diff output text [text/x-diff] Strength = 53@118: ConTeXt document text [] Strength = 52@16: C [] Strength = 52@26: Lisp/Scheme program text [text/x-lisp] Strength = 52@49: Python script text executable [text/x-python] Strength = 52@17: Tcl/Tk script text executable [text/x-tcl] Strength = 51@16: Node.js script text executable [application/javascript] Strength = 51@11: Lua script text executable [text/x-lua] Strength = 51@9: Tcl script text executable [text/x-tcl] Strength = 51@40: TeX document text [text/x-tex] Strength = 51@43: LaTeX document text [text/x-tex] Strength = 51@61: LaTeX auxiliary file [text/x-tex] Strength = 50@109: DCL command file [] Strength = 50@54: Linux make config build file [] Strength = 50@10: Perl script text [text/x-perl] Strength = 50@18: Perl script text [text/x-perl] Strength = 50@21: Tcl/Tk script text executable [text/x-tcl] Strength = 49@14: Node.js script text executable [application/javascript] Strength = 49@15: Lua script text executable [text/x-lua] Strength = 49@46: Ruby script text [text/x-ruby] Strength = 49@47: HTML document text [text/html] Strength = 49@13: Tcl script text executable [text/x-tcl] Strength = 49@19: Tcl/Tk script text executable [text/x-tcl] Strength = 49@77: LaTeX sorted glossary [] Strength = 48@6: binscii (apple ][) text [] Strength = 48@13: Lua script text executable [text/x-lua] Strength = 48@26: BSD makefile script text [text/x-makefile] Strength = 48@53: SVG XML document [image/svg+xml] Strength = 48@132: Web browser cookie text [] Strength = 48@11: Tcl script text executable [text/x-tcl] Strength = 47@113: Variant Call Format (VCF) [] Strength = 47@12: Node.js script text executable [application/javascript] Strength = 47@10: C program text (from flex) [] Strength = 47@34: automake makefile script text [text/x-makefile] Strength = 47@134: Konqueror cookie text [] Strength = 47@21: METAFONT transcript text [] Strength = 47@36: GNU Info text [text/x-info] Strength = 47@78: Makeindex log file [] Strength = 46@27: FrameMaker Dictionary text [application/x-mif] Strength = 46@20: BSD makefile script text [text/x-makefile] Strength = 46@30: BSD makefile script text [text/x-makefile] Strength = 46@9: MS Windows 95 Internet shortcut text [] Strength = 46@15: Tcl/Tk script text executable [text/x-tcl] Strength = 46@75: LaTeX sorted index [] Strength = 45@8: Node.js script text executable [application/javascript] Strength = 45@9: Lua script text executable [text/x-lua] Strength = 45@8: Perl script text [text/x-perl] Strength = 45@16: Perl script text [text/x-perl] Strength = 45@100: XML document text [text/xml] Strength = 45@7: Tcl script text executable [text/x-tcl] Strength = 45@90: BibTeX text file [] Strength = 44@9: Inform source text [] Strength = 44@34: Texinfo source text [text/x-texinfo] Strength = 44@76: LaTeX raw glossary [] Strength = 44@89: BibTeX text file [] Strength = 43@10: Node.js script text executable [application/javascript] Strength = 43@75: HTML document text [text/html] Strength = 43@78: HTML document text [text/html] Strength = 43@94: HTML document text [text/html] Strength = 43@5: SiSU text insert [] Strength = 43@8: SiSU text master [] Strength = 43@67: LaTeX document text [text/x-tex] Strength = 43@96: BibTeX text file [] Strength = 42@991: Squeak program text [] Strength = 42@63: HTML document text [text/html] Strength = 42@66: HTML document text [text/html] Strength = 42@81: HTML document text [text/html] Strength = 42@84: HTML document text [text/html] Strength = 42@87: HTML document text [text/html] Strength = 42@90: HTML document text [text/html] Strength = 42@26: Tcl script [] Strength = 42@20: TeX transcript text [] Strength = 42@95: BibTeX text file [] Strength = 42@106: TeX font aliases text file [] Strength = 41@176: Sequence Alignment/Map (SAM) [] Strength = 41@27: C source text [text/x-c] Strength = 41@43: C source text [text/x-c] Strength = 41@49: C source text [text/x-c] Strength = 41@52: C source text [text/x-c] Strength = 41@6: Node.js script text executable [application/javascript] Strength = 41@10: DOS batch file text [text/x-msdos-batch] Strength = 41@54: Perl POD document text [] Strength = 41@57: HTML document text [text/html] Strength = 41@60: HTML document text [text/html] Strength = 41@69: HTML document text [text/html] Strength = 41@72: HTML document text [text/html] Strength = 41@11: SiSU text [] Strength = 41@74: LaTeX raw index file [] Strength = 41@94: BibTeX text file [] Strength = 41@16: btoa'd text [] Strength = 41@266: [] Strength = 40@12: Algol 68 source text [text/x-Algol68] Strength = 40@612: PLS playlist text [] Strength = 40@6: Exuberant Ctags tag file text [] Strength = 40@6: diff output text [text/x-diff] Strength = 40@80: X11 BDF font text [] Strength = 40@7: C program text (from lex) [] Strength = 40@12: lex description text [] Strength = 40@20: Lisp/Scheme program text [text/x-lisp] Strength = 40@24: Lisp/Scheme program text [text/x-lisp] Strength = 40@6: M4 macro processor script text [text/x-m4] Strength = 40@8: makefile script text [text/x-makefile] Strength = 40@27: OS/2 REXX batch file text [] Strength = 40@29: OS/2 REXX batch file text [] Strength = 40@47: Perl POD document text [] Strength = 40@53: Perl POD document text [] Strength = 40@23: SoftQuad Raster Format text [] Strength = 40@93: BibTeX text file [] Strength = 40@98: BibTeX-file{ BibTex text file (with full header) [] Strength = 40@104: BibTeX custom bibliography style text file [] Strength = 40@15: troff or preprocessor input text [text/troff] Strength = 39@325: Software Tools format archive text [] Strength = 39@34: C source text [text/x-c] Strength = 39@89: PHP script text [text/x-php] Strength = 39@91: PHP script text [text/x-php] Strength = 39@613: X pixmap image text [image/x-xpmi] Strength = 39@74: TeXmacs document text [text/texmacs] Strength = 39@14: makefile script text [text/x-makefile] Strength = 39@79: MSX SCMD source MML file [] Strength = 39@124: exported SGML document text [] Strength = 39@86: BibTeX text file [] Strength = 39@9: troff or preprocessor input text [text/troff] Strength = 39@11: troff or preprocessor input text [text/troff] Strength = 39@17: troff or preprocessor input text [text/troff] Strength = 39@21: troff or preprocessor input text [text/troff] Strength = 39@25: ditroff output text [] Strength = 38@8: Algol 68 source text [text/x-Algol68] Strength = 38@5: assembler source text [text/x-asm] Strength = 38@8: BCPL source text [text/x-bcpl] Strength = 38@10: BCPL source text [text/x-bcpl] Strength = 38@26: Clojure module source text [text/x-clojure] Strength = 38@29: Clojure module source text [text/x-clojure] Strength = 38@59: awk or perl script text [] Strength = 38@8: diff output text [text/x-diff] Strength = 38@10: diff output text [text/x-diff] Strength = 38@6: ASCII vfont text [] Strength = 38@510: FIG image text [] Strength = 38@142: Linux kernel symbol map text [] Strength = 38@18: Lisp/Scheme program text [text/x-lisp] Strength = 38@12: makefile script text [text/x-makefile] Strength = 38@6: X-Post-It-Note text [] Strength = 38@50: Perl POD document text [] Strength = 38@52: Perl POD document text [] Strength = 38@51: Ruby script text [text/x-ruby] Strength = 38@54: Ruby script text [text/x-ruby] Strength = 38@125: exported SGML subdocument text [] Strength = 38@14: SiSU text [] Strength = 38@17: SiSU text [] Strength = 38@6: Sketch document text [] Strength = 38@55: Solaris xcurses screen image [] Strength = 38@71: TeX document text [] Strength = 38@88: BibTeX text file [] Strength = 38@91: BibTeX text file [] Strength = 38@13: troff or preprocessor input text [text/troff] Strength = 38@19: troff or preprocessor input text [text/troff] Strength = 37@6: Algol 68 source text [text/x-Algol68] Strength = 37@14: Algol 68 source text [text/x-Algol68] Strength = 37@11: assembler source text [text/x-asm] Strength = 37@610: M3U playlist text [] Strength = 37@23: C source text [text/x-c] Strength = 37@31: C source text [text/x-c] Strength = 37@37: C source text [text/x-c] Strength = 37@40: C source text [text/x-c] Strength = 37@46: C source text [text/x-c] Strength = 37@218: Smart Game Format [] Strength = 37@286: Smart Game Format [] Strength = 37@19: Java source [text/x-java] Strength = 37@22: Lisp/Scheme program text [text/x-lisp] Strength = 37@10: makefile script text [text/x-makefile] Strength = 37@5: Pascal source text [text/x-pascal] Strength = 37@49: Perl POD document text [] Strength = 37@51: Perl POD document text [] Strength = 37@68: Python script text executable [text/x-python] Strength = 36@10: Algol 68 source text [text/x-Algol68] Strength = 36@7: assembler source text [text/x-asm] Strength = 36@9: assembler source text [text/x-asm] Strength = 36@13: assembler source text [text/x-asm] Strength = 36@15: assembler source text [text/x-asm] Strength = 36@17: assembler source text [text/x-asm] Strength = 36@12: CDDB(tm) format CD text data [] Strength = 36@23: Clojure module source text [text/x-clojure] Strength = 36@15: RCS/CVS diff output text [text/x-diff] Strength = 36@145: Linux Software Map entry text [] Strength = 36@146: Linux Software Map entry text (new format) [] Strength = 36@16: Lisp/Scheme program text [text/x-lisp] Strength = 36@6: makefile script text [text/x-makefile] Strength = 36@13: Mup music publication program input text [] Strength = 36@48: Perl POD document text [] Strength = 36@65: GEDCOM genealogy text [] Strength = 36@87: BibTeX text file [] Strength = 36@92: BibTeX text file [] Strength = 36@13: uuencoded or xxencoded text [] Strength = 36@20: ship'd binary text [] Strength = 30@118: broken XML document text [text/xml] Strength = 28@126: exported SGML document text [] Strength = 18@38: a [] Strength = 17@30: a [] Strength = 2@7: FORTRAN program text [text/x-fortran] Strength = 2@29: Tcl script [] Set 1: Binary patterns: Text patterns:
Tags:
Steps To Reproduce:
Additional Information:	■ file --version file-5.37 magic file from /usr/share/file/misc/magic ■ uname -srvmo Linux 5.4.2-arch1-1 0000001 SMP PREEMPT Thu, 05 Dec 2019 12:29:40 +0000 x86_64 GNU/Linux Thank you for maintaining this essential utility.
Attached Files:	2019-12-11.mp4.8k (8,192 bytes) 2020-02-14 01:56 https://bugs.astron.com/file_download.php?file_id=115&type=bug 2020-01-22.mp4.8k (8,192 bytes) 2020-02-14 01:56 https://bugs.astron.com/file_download.php?file_id=118&type=bug 2019-12-25.mp4.8k (8,192 bytes) 2020-02-14 01:56 https://bugs.astron.com/file_download.php?file_id=116&type=bug 2020-01-15.mp4.8k (8,192 bytes) 2020-02-14 01:56 https://bugs.astron.com/file_download.php?file_id=117&type=bug Bonus.mp4.8k (8,192 bytes) 2020-02-14 01:58 https://bugs.astron.com/file_download.php?file_id=119&type=bug

Notes
(0003354) christos    2020-02-12 22:33	Can you attatch the first few K of this file?
(0003360) Kid    2020-02-14 01:56	Certainly. Here are four samples, identical in their misidentification.
(0003361) Kid    2020-02-14 01:58	And here is a bonus MP4 sample that is misidentified as application/octet-stream. Should I report a second bug?
(0003462) christos    2020-08-25 00:47	The first four are fixed. The last one I am looking into.
(0003463) christos    2020-08-25 01:29	Bonus.pm4 is not an mp4 file but: https://en.wikipedia.org/wiki/MPEG_transport_stream This really does not have any magic (yes it starts with a G)... But that's not enough.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
87	[file] General	feature	N/A	2019-06-12 17:56	2020-08-24 12:56
Reporter:	dbrezack	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	feedback	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Support for Flattened Device Tree files (fdt)
Description:	I think it would be helpful if the file command supported Flattened Device Tree files (fdt). The file magic is "d0 0d fe ed" These resources may be helpful https://wiki.freebsd.org/FlattenedDeviceTree https://github.com/superna9999/pyfdt Thanks Data Brezack
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003254) christos    2019-06-16 00:08	You mean dtb and it already does: sun50i-h5-nanopi-neo-plus2.dtb: Device Tree Blob version 17, size=25978, boot CPU=0, string block size=1870, DT structure block size=23028
(0003439) yegorich    2020-08-03 07:59	Yes, file detects dtb files. But what about itb files that are composed using its source files? This way you can package several images like Linux kernel, related DTB files in one image. It also has "d0 0d fe ed" as magic, but the other fields seem to be different. See this PDF for more information: https://elinux.org/images/f/f4/Elc2013_Fernandes.pdf
(0003456) christos    2020-08-23 19:27	I looked quite a bit for fdt examples, even at the uboot source and I could not make sense of it. Do you have example files?
(0003461) yegorich    2020-08-24 12:56	This deb package [1] has kernel-fit.itb file in CONTENTS/boot folder. kernel-fit.itb holds zImage and a number of DTB files. The source file (ITS) can be found here [2]. [1] ftp://ftp.visionsystems.de/pub/multiio/OnRISC/Baltos/deb/stretch/kernel_3.18.32-3.deb [2] https://github.com/visionsystemsgmbh/onrisc_br_bsp/blob/master/board/vscom/baltos/kernel-fit-intree.its

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
135	[file] General	minor	always	2020-01-30 18:17	2020-08-23 19:31
Reporter:	jj05	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	feedback	Product Version:	5.38
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Misdetection text/troff instead of text/plain for MT940 files
Description:	This isn't a troff file, so shouldn't be detected as one
Tags:
Steps To Reproduce:	$ file mt940-troff-bug.txt mt940-troff-bug.txt: troff or preprocessor input, UTF-8 Unicode (with BOM) text, with CRLF, LF line terminators
Additional Information:
Attached Files:	mt940-troff-bug.txt (639 bytes) 2020-01-30 18:17 https://bugs.astron.com/file_download.php?file_id=101&type=bug

Notes
(0003349) jj05    2020-01-30 18:20	More information about MT940 format: http://martin.hinner.info/bankconvert/swift_mt940_942.pdf
(0003352) christos    2020-02-12 22:25	Restricted troff not to match .[0-9]
(0003405) jj05    2020-05-12 11:53	This is available to test?
(0003457) christos    2020-08-23 19:31	The fix should be available on HEAD

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
104	[file] General	minor	have not tried	2019-09-10 21:04	2020-08-23 19:26
Reporter:	Ilrandar	Platform:
Assigned To:	christos	OS:	ArchLinux
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.37
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	pdf file incorrectly reported as `data`
Description:	Some pdf files downloaded from the internet are incorrectly reported as `data` by file. Their associated mime-type is `application/octet-stream` and not `application/pdf`. I join such a pdf to this report.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	certificat_scolarité_l2_eco.pdf (1,184,843 bytes) 2019-09-10 21:04 https://bugs.astron.com/file_download.php?file_id=77&type=bug

Notes
(0003288) christos    2019-09-11 14:42	These are the first few lines of the file: HTTP/1.1 200 OK Date: Tue, 10 Sep 2019 08:38:20 GMT Server: Apache/2.4.38 (Debian) Content-Disposition: attachment; filename="21808995-2019-certificat-scolarite.pdf" Cache-Control: no-cache, private X-RateLimit-Limit: 60 X-RateLimit-Remaining: 58 Content-Length: 1184531 Content-Type: application/pdf Here's where the pdf file starts: %PDF-1.3 The tool you used to download it or the original file has junk in front. Of course some browsers ignore the junk and process it as a pdf file (because users want things to just work), but this is just crappy behavior. Most application will not open it properly, and it is also a security issue since you can masquerade files this way. It is also fragile. How many lines does it try to parse? 10? 1K of data? Who knows. Depends on the implementation. Of course file can also be modified to mimick this behavior at the loss of efficiency and encouraging people to produce junk...
(0003295) Ilrandar    2019-09-11 17:07	Oh, I didn’t know I could open pdf files with a text editor. I don’t think you should ignore junk in front of file. I just needed some way to get this file (and a few other) to be recognized as pdf files, but if I can just open them and get rid of the leading incorrect lines, I will just do it. Thank you for your answer. As far as I’m concerned, you can consider this issue closed.
(0003432) holmesmr.pf    2020-06-29 16:21	I've noticed a similar issue with other technically-malformed PDF files, but it appears almost every PDF reader and tool not using libmagic supports these. As an aside, it does appear a rule to implement this is actually in place [1]. However it appears that due to a longstanding issue, searching for text strings in files detected as binary doesn't work[2], so this rule is never successfully hit (this can be verified by the fact that a single line text file with the string '%PDF-1.7' at the end will be detected as 'PDF document, version 1.7, ASCII text'. Presumably this rule should either be removed or a workaround or fix for the search issue is required. [1]: https://github.com/file/file/blob/FILE5_39/magic/Magdir/pdf#L39 [2]: https://github.com/file/file/blob/FILE5_39/magic/Magdir/vorbis#L21
(0003433) christos    2020-06-29 16:50	Actually there is a simple fix to make search work for binary data (add /b). I will do that and it will probably fix your problem.
(0003434) holmesmr.pf    2020-06-29 16:56	My apologies - I was apparently looking at an old manpage that didn't have documentation on this. Having tested locally with a custom magic file this does appear to work correctly.
(0003455) christos    2020-08-23 19:26	Confirmed fixed

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
185	[file] General	minor	have not tried	2020-08-20 16:08	2020-08-22 18:46
Reporter:	marius851000	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	file doesn't know the extension of GIF/TIFF/PSD file
Description:	running ``file --extension`` on either a gif, a tiff or a pdf file result to giving the extension ??? (unknown)
Tags:
Steps To Reproduce:	download a GIF file (for example, https://i.imgur.com/DfQqM.gif), a TIFF file (for example, https://www.fileformat.info/format/tiff/sample/3794038f08df403bb446a97f897c578d/download , from https://www.fileformat.info/format/tiff/sample/index.htm) and a PSD file (for example, here: https://www.deviantart.com/edowaado/art/Doctor-Whooves-Epilogue-Pt-2-410825994 (click on download)). Then run ``file --extension`` on the downloaded file, and it should result in ``<filename> : ???`` rather than ``<filename> : gif/tiff/psd``
Additional Information:	Here is a patch to solve this, based on the github mirror.
Attached Files:	add_extension_gif_psd_tiff.diff (819 bytes) 2020-08-20 16:08 https://bugs.astron.com/file_download.php?file_id=153&type=bug

Notes
(0003454) christos    2020-08-22 18:46	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
181	[file] General	minor	N/A	2020-08-15 23:06	2020-08-22 18:31
Reporter:	abon	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	Minor Opus Tweaks
Description:	Thanks for fixing the Opus output. I've included a diff (opus.diff) that makes the following small changes: 1. Update the Opus specification link to the final version. 2. Add a comma and change %d -> %u in the version string. 3. Specify that the sample rate detected is only the _input_ sample rate, as per the 5th item of https://tools.ietf.org/html/rfc7845#section-5.1
Tags:
Steps To Reproduce:
Additional Information:	Additionally, I wanted to add the Output Gain field as well, but I had some issues with using the leshort type on the field, which is a Q7.8 number: Using (as a first try): >>>>44 leshort !0 \b, %d Output Gain The above (falsely?) converts the two-byte LE short (#xF1) to an unsigned short instead of what I believe should be a signed short. FWIW, the attached cast.diff makes `file' produce the result expected (-3840). Using: >>>>44 leshort/256 !0 \b, %d Output Gain The above appears to convert the LE short to unsigned before getting to the `mprint' function, as even with cast.diff applied I get 241 instead of the expected -15. This is also the case when using the short type, as (>>>>44 short !0 \b, %d Output Gain) yields -3840 (expected), but (>>>>44 short/256 !0 \b, %d Output Gain) yields 241. Perhaps it's too much effort for a single field like this, but to fully convert the Q7.8 number there would likely need to be support for this form: >>>>44 leshort/256.0 !0 \b, %g Output Gain Where it converts the LE short to a floating point to print the fractional part as well. That or adding a new type, which seems excessive.
Attached Files:	opus.diff (929 bytes) 2020-08-15 23:06 https://bugs.astron.com/file_download.php?file_id=151&type=bug cast.diff (358 bytes) 2020-08-15 23:06 https://bugs.astron.com/file_download.php?file_id=152&type=bug

Notes
(0003453) christos    2020-08-22 18:31	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
182	[file] General	minor	always	2020-08-16 22:55	2020-08-22 18:18
Reporter:	jpalus	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	ELF shared object without dynamic section considered dynamically linked
Description:	VirtualBox creates a shared object:     $ readelf -h VBoxDDR0.debug|grep Type       Type: DYN (Shared object file) which lacks dynamic section and therefore does not have any linked libraries, nor has interpreter:     $ readelf -d VBoxDDR0.debug          There is no dynamic section in this file. Yet file started to recognize it as dynamically linked:     $ file VBoxDDR0.debug     VBoxDDR0.debug: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=52d7486748cc2a8387793008f2fdbdb1761f65e3, stripped I guess it is a result of: https://github.com/file/file/commit/028a15617a7f2c9172e3ac2d903af0f03010c8b4 Perhaps it would be better to judge if object is "dynamically linked" based on dynamic section existence?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003452) christos    2020-08-22 18:18	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
184	[file] General	minor	always	2020-08-19 16:31	2020-08-22 18:17
Reporter:	vinc17	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.38
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.39
		Target Version:
Summary:	files starting with "*** " misidentified as diff
Description:	Files starting with "*** " are misidentified as diff.
Tags:
Steps To Reproduce:	$ echo '*** Title' | file - /dev/stdin: diff output, ASCII text
Additional Information:	The use of "***" is quite general in text files and allows one to highlight text, thus it should not be used alone to detect diff output. I had reported this bug 6 years ago in the Debian BTS (for file 5.17): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744924
Attached Files:

Notes
(0003451) christos    2020-08-22 18:17	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
183	[file] General	minor	always	2020-08-18 09:37	2020-08-22 18:04
Reporter:	liuzhiqiang	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	“PR 93：file incorrectly recognizes -static-pie binaries” should be reopened.
Description:	“PR 93：file incorrectly recognizes -static-pie binaries”should be reopened. To solve “PR 93：file incorrectly recognizes -static-pie binaries”, one patch (24c9c086cd7c5) is introduced in v5.38. However, the patch will lead to a new problem, "file incorrectly recognizes shared objects" problem. So, patch (028a15617a7f) is created to undo the patch (24c9c086cd7c5) to solve "file incorrectly recognizes shared objects" problem. Finally, "file incorrectly recognizes shared objects" problem is solved, while “PR 93：file incorrectly recognizes -static-pie binaries”problem occurs again. So we need to solve it. “PR 93：file incorrectly recognizes -static-pie binaries”: https://bugs.astron.com/view.php?id=93
Tags:
Steps To Reproduce:	file version: v5.39 details can be found in https://bugs.astron.com/view.php?id=93.     1. Create a simple hello word C program 2. Compile it using gcc -fPIE -static-pie -o test test.c 3. Run file on the resulting binary Output: test: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=4594afb38f3f60aaad10d08ab519fcaeae55ee70, for GNU/Linux 3.2.0, not stripped It should actually be reported as statically linked, check with ldd: $ ldd test     statically linked
Additional Information:
Attached Files:

Notes
(0003449) christos    2020-08-22 14:30	Well, this is because static-pie binaries are special... (In order to be loaded anywhere they have a dynamic section). 1. run 'readelf -d test': A dynamic section in a static binary? 2. run 'gcc -fPIE -static -static-pie -o test test.c': oops it does not work :-) /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/crtbeginT.o: relocation R_X86_64_32 against hidden symbol `__TMC_END__' can not be used when making a PIE object collect2: error: ld returned 1 exit status I guess file detection can be improved
(0003450) christos    2020-08-22 18:04	Fixed, thanks. It will now call them "static-pie linked".

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
178	[file] General	minor	always	2020-08-12 01:51	2020-08-15 12:40
Reporter:	abon	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	Opus audio information not displayed for Opus files
Description:	`file' does not print out Opus audio information for Opus files. Only the string "Ogg data, Opus audio," is shown. Compare: file test.ogg test.ogg: Ogg data, Vorbis audio, stereo, 44100 Hz, ~128000 bps, created by: Xiph.Org libVorbis I file test.opus test.opus: Ogg data, Opus audio,
Tags:	magic
Steps To Reproduce:	0. Encode a file to Opus using any of opusenc, ffmpeg, or gstreamer. 1. Call `file' on the resulting opus file.
Additional Information:
Attached Files:

Notes
(0003448) christos    2020-08-15 12:40	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
177	[file] General	minor	always	2020-08-11 09:24	2020-08-14 19:30
Reporter:	ojab	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	Add GNU/Emacs pdumper image support
Description:	``` $ file /usr/libexec/emacs/27.1/x86_64-pc-linux-gnu/emacs.pdmp /usr/libexec/emacs/27.1/x86_64-pc-linux-gnu/emacs.pdmp: data ```
Tags:
Steps To Reproduce:
Additional Information:	Patch via git mirror master in the attached file, ``` $ /usr/local/bin/file /usr/libexec/emacs/27.1/x86_64-pc-linux-gnu/emacs.pdmp /usr/libexec/emacs/27.1/x86_64-pc-linux-gnu/emacs.pdmp: GNU/Emacs pdumper image ```
Attached Files:	emacs_pdumper.patch (501 bytes) 2020-08-11 09:24 https://bugs.astron.com/file_download.php?file_id=149&type=bug

Notes
(0003446) christos    2020-08-14 19:30	Added thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
179	[file] General	minor	have not tried	2020-08-13 13:33	2020-08-14 19:22
Reporter:	devnexen	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	libmagic: Haiku build fix proposal
Description:	As is the whole build however in other contexts (e.g. PHP), the build breaks as Haiku already define unichar and differs from this one thus renaming the whole type here.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	90.diff.txt (9,882 bytes) 2020-08-13 13:33 https://bugs.astron.com/file_download.php?file_id=150&type=bug

Notes
(0003445) christos    2020-08-14 19:22	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
176	[file] General	minor	always	2020-08-05 12:24	2020-08-09 16:57
Reporter:	vinc17	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.38
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	Messages for Git objects have an incorrect id
Description:	The messages for Git objects have an incorrect id: only the first sequence of decimal digits is retrieved instead of the full sequence of hexadecimal digits. This is due to a bad regexp in "magic/Magdir/git".
Tags:
Steps To Reproduce:	$ echo "commit d617e0c0ca8fac42361b00c8861eb2a59ab7a7d8" | file - /dev/stdin: Git commit 617
Additional Information:	This issue is present in file 5.38 (current version in Debian/unstable), but according to https://github.com/file/file/blob/master/magic/Magdir/git it is still not fixed (thus present in file 5.39 too, I suppose). To fix it, replace each occurrence of "[0-9]+" by "[0-9a-f]+" (I've attached a patch). After this change, $ echo "commit d617e0c0ca8fac42361b00c8861eb2a59ab7a7d8" | file - /dev/stdin: Git commit d617e0c0ca8fac42361b00c8861eb2a59ab7a7d8
Attached Files:	file-git-messages.patch (566 bytes) 2020-08-05 12:24 https://bugs.astron.com/file_download.php?file_id=148&type=bug

Notes
(0003444) christos    2020-08-09 16:57	Thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
175	[file] General	minor	always	2020-08-04 11:49	2020-08-09 16:54
Reporter:	arnep	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.38
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	TeamViewer Session format not recognized
Description:	I have a TeamViewer Session file that is not correctly recognized For format see: http://www.jerrysguide.com/tips/demystify-tvs-file-format.html "The header of TVS file is a multi-line ASCII string. The first line is Magic Number “TVS”."
Tags:	magic
Steps To Reproduce:	$ file 494 494: data Expected: "TeamViewer Session" (FAIL) $ file 494 --mime-encoding 494: binary Expected: binary (OK) $ file 494 --mime-type 494: application/octet-stream Expected: something TeamViewer related ... maybe application/tvs or application/teamviewer (FAIL) $ file 494 --extension 494: ??? Expecte: tvs (FAIL)
Additional Information:
Attached Files:

Notes
(0003443) christos    2020-08-09 16:54	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
174	[file] General	minor	always	2020-08-03 12:41	2020-08-09 16:43
Reporter:	petre	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	CSV files identified as "application/csv" instead of registered "text/csv"
Description:	The new CSV file identification is returning "application/csv". According to RFC 4180, the registered mime type is 'text/csv'. "application/csv" is not registered at all, see https://www.iana.org/assignments/media-types/media-types.xhtml If there is no valid reason to use "application/csv", that I'm not aware of, could this be updated, please?
Tags:
Steps To Reproduce:	(via python-magic) >>> import magic >>> magic.from_buffer("a,b,c\nd,e,f\ng,h,i\n", mime=True) 'application/csv'
Additional Information:	Relevant code location: https://github.com/file/file/blob/FILE5_39/src/is_csv.c#L153
Attached Files:

Notes
(0003442) christos    2020-08-09 16:43	Thanks, fixed!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
173	[file] General	feature	N/A	2020-07-25 18:57	2020-08-09 16:41
Reporter:	Sascha Brawer	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	Recognize E57 files
Description:	Could libmagic recognize E57 files, used to store three-dimensional models, typically from laser scanners? E57 files start with the magic eight byte sequence x'41 53 54 4D 2D 45 35 37'; or in ASCII: "ASTM-E57". MIME type: model/e57 MIME registration: https://www.iana.org/assignments/media-types/model/e57 File extension: .e57 Sample files: http://www.libe57.org/data.html Reference implementation: http://www.libe57.org/ File format overview: https://www.ri.cmu.edu/pub_files/2011/1/2011-huber-e57-v3.pdf The libmagic configuration will probably look similar to the following: ######### 0 string ASTM-E57 ASTM E57 three-dimensional model !:mime model/e57 !:ext e57 ######### Thank you in advance! Best regards, — Sascha Brawer, sascha@brawer.ch
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003438) Sascha Brawer    2020-07-27 13:51	Or maybe just this, since it’s shorter: ######### 0 string ASTM-E57 E57 model !:mime model/e57 !:ext e57 #########
(0003441) christos    2020-08-09 16:41	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
172	[file] General	minor	have not tried	2020-07-19 17:52	2020-08-09 16:38
Reporter:	GerbilSoft	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	console: Fix CGB detection
Description:	CGB detection currently requires the old licensee code to be set to 0x33. This is correct for SGB detection, but it seems the CGB boot ROM doesn't care about this. There are several unlicensed and homebrew ROMs that don't have the old licensee code set correctly, but they *do* function in CGB mode.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	0001-console-CGB-doesn-t-require-licensee-code-to-be-0x33.patch (1,013 bytes) 2020-07-19 17:52 https://bugs.astron.com/file_download.php?file_id=147&type=bug

Notes
(0003440) christos    2020-08-09 16:38	Thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
169	[file] General	minor	always	2020-06-27 16:25	2020-08-09 16:36
Reporter:	colejohnson66	Platform:	Linux
Assigned To:	christos	OS:	Arch
Priority:	low	OS Version:	Rolling (200627)
Status:	feedback	Product Version:	5.39
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Uncompressed Git Objects Detected as "zlib compressed data"
Description:	Inside `.git/objects`, some files are compressed and others aren't. The uncompressed ones are identifiable by the string "blob " (62 6c 6f 62 20 in big endian) at offset 0x7 followed by (in decimal?) the size of the blob. These uncompressed ones are mistakenly identified as "zlib compressed data"
Tags:	magic
Steps To Reproduce:	Open a folder containing a .git folder and run: find .git/objects -type f -print0 | xargs -0 -I {} xxd '{}' | grep 'blob' If anything prints, there is an uncompressed blob stored inside Git. Afterwards, run: find .git/objects -type f -print0 | xargs -0 -I {} file '{}' Notice how every file printed (with the exception of the `.pack` and `.idx` files) says "zlib compressed data".
Additional Information:
Attached Files:

Notes
(0003431) colejohnson66    2020-06-28 21:15	A better command to list uncompressed objects is: find .git/objects -type f -print0 | xargs -0 -I {} sh -c "printf '{}: ' && xxd '{}'" | grep "blob " This will list the file name along with the hex dump. I've noticed that (on my repositories) that most are PNG files I've committed. I assume they're stored uncompressed as the pixel data is already compressed (rendering (a second) compression useless)
(0003435) christos    2020-07-04 23:32	can you attach a couple of those blob files here?

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
171	[file] General	minor	have not tried	2020-06-28 16:36	2020-07-06 22:39
Reporter:	GerbilSoft	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	New magic: More RIFF formats, Sufami Turbo, High Sierra, more textures
Description:	This patch set adds the following magic: * RIFF: Added more codecs from the WAVE/AVI codec registry: https://www.iana.org/assignments/wave-avi-codec-registry/wave-avi-codec-registry.xml * Detect Sufami Turbo ROM images. Sufami Turbo is a mini-cartridge adapter for the Super Famicom. * filesystem: Display the volume label on High Sierra discs. * images: Added .crn files. (Crunch compressed textures) * images: Initial support for BasisLZ texture format. * elf: Detect PlayStation 2 IOP modules. * console: Detect Nintendo 3DS Banner Model Data. * images: Khronos KTX2: Updated supercompression methods for 2.0.rc4.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	file.2020-06-28.tar.gz (7,632 bytes) 2020-06-28 16:36 https://bugs.astron.com/file_download.php?file_id=146&type=bug

Notes
(0003437) christos    2020-07-06 22:39	Added! Thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
170	[file] General	minor	always	2020-06-28 09:00	2020-07-04 23:33
Reporter:	delroth	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.39
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	Bad magic for Web Assembly wasm files
Description:	On file 5.38: $ file hello1.wasm hello1.wasm: WebAssembly (wasm) binary module version 0x1 (MVP) On file 5.39: $ file hello1.wasm hello1.wasm: ERROR: Bad magic format `version %#x (MVP)' (bad format char: #)
Tags:
Steps To Reproduce:	Test file attached.
Additional Information:
Attached Files:	hello1.wasm (47 bytes) 2020-06-28 09:00 https://bugs.astron.com/file_download.php?file_id=145&type=bug

Notes
(0003436) christos    2020-07-04 23:33	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
168	[file] General	major	always	2020-06-15 20:36	2020-06-18 16:25
Reporter:	gyakovlev	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.40
		Target Version:
Summary:	file-5.39[seccomp][ppc64]: error: invalid application of 'sizeof' to incomplete type 'struct termios'
Description:	downstream bug: https://bugs.gentoo.org/728416 file-5.39/src/seccomp.c: In function 'enable_sandbox_full': file-5.39/work/file-5.39/src/seccomp.c:194:19: error: invalid application of 'sizeof' to incomplete type 'struct termios'   194 | ALLOW_IOCTL_RULE(TCGETS);       | ^~~~~~ file-5.39/work/file-5.39/src/seccomp.c:194:2: note: in expansion of macro 'ALLOW_IOCTL_RULE'   194 | ALLOW_IOCTL_RULE(TCGETS);       | ^~~~~~~~~~~~~~~~ make[3]: *** [Makefile:558: seccomp.o] Error 1 make[3]: *** Waiting for unfinished jobs...
Tags:
Steps To Reproduce:
Additional Information:	On PPC64, TCGETS is defined in terms of struct termios, so it must include termios.h adding #ifdef __powerpc64__ #include <termios.h> #endif to src/seccomp.c fixes the build.
Attached Files:

Notes
(0003429) gyakovlev    2020-06-15 20:53	someone pointed out it may be not ppc64 specific and it should probably just include <termios.h> unconditionally.
(0003430) christos    2020-06-18 16:25	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
153	[tcsh] General	crash	always	2020-03-26 15:53	2020-06-10 22:17
Reporter:	sharifib	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:	6.22.02
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Segfault involving piping to builtin + precmd
Description:	Piping to a builtin command seems to pollute the job table (adds an entry for the pipeline). In general, tcsh seems to recover and remove the bad job when you try to interact with it. However, if there's a precmd alias, it can segfault instead.
Tags:
Steps To Reproduce:	> echo $tcsh 6.22.02 > fg fg: No current job. > echo | source /dev/stdin > > jobs [1] + Running echo | > alias precmd true > fg echo | fg: No such job (badjob). > fg Segmentation fault
Additional Information:
Attached Files:

Notes
(0003428) christos    2020-06-10 22:17	Just an update: the code is horribly complicated and kludgy there and any change I made, made it worse.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
147	[file] General	minor	have not tried	2020-02-23 04:55	2020-06-07 19:22
Reporter:	hlein	Platform:	amd64
Assigned To:	christos	OS:	Linux
Priority:	normal	OS Version:
Status:	feedback	Product Version:	5.38
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Some PGP files encrypted with RSA keys are not recognized
Description:	Magdir/pgp includes rules like: # 2048b RSA encrypted data 0 string \x85\x01\x0c\x03 PGP RSA encrypted session key - ... >13 string \x07\xfa >13 string \x07\xf9 >271 byte 0xd2 . I have some files that are encrypted to a 2048b RSA key where the third byte is 0x0b instead of 0x0c, and where the 13-14th bytes are 0x07 0xf8, one off the end of the above list of recognized values. I believe the patterns for 3072bit, and 4096bit RSA should be similarly expanded. Also, the last byte of 0xd2 is not always at the specified offset (271 for RSA2048, 527 for RSA4096, etc.). Sometimes it is one byte sooner. I think bytes 2&3 are actually a length, which is why if byte 3 is off-by-one, then the location of the 0xd2 byte is also off by one.
Tags:
Steps To Reproduce:	I have not managed to create such files on demand. And I cannot share the existing artifacts I have. Probably a sufficiently careful reading of gnupg source would add certainty, but... ow.
Additional Information:	I can't figure out the right way to say "expect either 0x0b or 0x0c here" without duplicating the entire pattern set into a new stanza, or unintended consequences like matching other files that are not intended. So, no patch this time.
Attached Files:

Notes
(0003397) christos    2020-03-20 16:38	I made a pass at changing the magic based on your description https://www.zoulas.com/~christos/Junk/pgp the h in the indirect offset could be H but it should be close.
(0003427) christos    2020-06-07 19:22	Can you test the change?

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
164	[file] General	minor	always	2020-05-20 17:53	2020-06-07 19:21
Reporter:	pombredanne	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	feedback	Product Version:	5.38
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Certificate data now reported as apple diskcopy 4.2 image
Description:	In previous versions the attached CERTIFICATE file (some signing public key/certificate) was reported as "data", with 5.38 is is reported as "apple diskcopy 4.2 image". (It comes from https://github.com/nexB/scancode-toolkit/blob/develop/tests/typecode/data/contenttype/certificate/CERTIFICATE )
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	CERTIFICATE (5,688 bytes) 2020-05-20 17:53 https://bugs.astron.com/file_download.php?file_id=143&type=bug

Notes
(0003426) christos    2020-06-07 19:21	This file appears not to be valid? Can you test its integrity on your side? [3:08pm] 2515>cc -DTEST_DER der.c [3:08pm] 2516>./a.out certificate 0 0-2 U,C,gen_time,22:0000000202003082162506092a864886f70d010702a0 1 2-4 U,P,eoc,0: 1 4-6 U,P,eoc,2:0200 a.out: corrupt der 1 8-12 U,C,seq,4294967295: [3:09pm] 2517>openssl x509 -in certificate -inform der -text unable to load certificate 18446744073709551615:error:0D0680A8:asn1 encoding routines:asn1_check_tlen:wrong tag:/net/quasar/src-5/NetBSD/src.acl/crypto/external/bsd/openssl/dist/crypto/asn1/tasn_dec.c:1130: 18446744073709551615:error:0D07803A:asn1 encoding routines:asn1_item_embed_d2i:nested asn1 error:/net/quasar/src-5/NetBSD/src.acl/crypto/external/bsd/openssl/dist/crypto/asn1/tasn_dec.c:290:Type=X509

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
165	[file] General	minor	always	2020-05-22 21:08	2020-06-07 19:03
Reporter:	pls	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.38
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.39
		Target Version:
Summary:	Valid JSON incorrectly identified as ASCII text
Description:	The following examples are all valid JSON, but fail to be identified as JSON as per `file [JSON FILE]` and are identified as ASCII text: 1. Empty object: {} 2. Object with values that are empty objects: {"foo": {}} . Similar problems occur with greater nesting. 3. Empty array: [] 4. Array with one element: ["foo"] 5. Object with values that are empty arrays: {"foo": []} . Like 2.), similar problems occur with greater nesting. Interestingly, {"foo": ["bar"]} is validated as JSON though. 6. Arrays containing empty objects: ["foo", "bar", {}]
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003425) christos    2020-06-07 18:49	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
167	[file] General	minor	always	2020-06-07 18:12	2020-06-07 18:17
Reporter:	vinc17	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.38
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.39
		Target Version:
Summary:	For XML, version="1.0" and version='1.0' are not handled in the same way
Description:	On XML files, the output depends on the type of quote character used for the version. This is not consistent.
Tags:
Steps To Reproduce:	Consider the following XML files: ==> file1.xml <== <?xml version="1.0"?> <root/> ==> file2.xml <== <?xml version='1.0'?> <root/> The only difference is the quote character used for the version (double quote vs single quote). But I get a difference in the output: $ file file?.xml file1.xml: XML 1.0 document, ASCII text file2.xml: XML 1.0 document text
Additional Information:
Attached Files:

Notes
(0003424) christos    2020-06-07 18:17	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
166	[file] General	feature	N/A	2020-05-23 23:37	2020-06-07 18:13
Reporter:	polluks	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.38
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.39
		Target Version:
Summary:	Magic for PPU
Description:	--- pascal.bak 2020-05-24 00:13:16 +0200 +++ pascal 2020-05-24 01:09:58 +0200 @@ -8,3 +8,7 @@  #!:mime text/x-pascal  #0 regex \^record Pascal source text  #!:mime text/x-pascal + +# Free Pascal +0 string PPU Pascal unit +>3 string x \b, version %s
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	pascal (443 bytes) 2020-05-23 23:37 https://bugs.astron.com/file_download.php?file_id=144&type=bug

Notes
(0003423) christos    2020-06-07 18:13	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
162	[file] General	feature	always	2020-05-17 12:54	2020-06-07 17:41
Reporter:	vinc17	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.38
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.39
		Target Version:
Summary:	should allow one to provided a non-existing -e / --exclude test
Description:	Currently, if one provides a non-existing -e / --exclude test, one gets a fatal error. This is a portability issue, for instance if one wishes to exclude some new test that has been added in some version of "file", but one uses various machines, having different versions of "file". With recent versions of "file", the test would be excluded. And with older versions, the test does not exist yet, so that excluding it should not change anything (instead of triggering an error like now). Example: the json test was added quite recently, and this was an issue, at least last year: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923396 Solution 1: Just ignore non-existing tests, because they can be future tests not available yet. So this is safe. Solution 2: Output a warning to stderr (e.g. to warn the user in case he would have mistyped the test name), and add away to disable the warnings (useful for scripts). Redirecting stderr to /dev/null would not be a solution as this would hide error messages too, which are useful to diagnostic problems. This could be implemented as an option in addition to -e / --exclude, such as -q / --quiet. This could also be an option in place of -e / --exclude, such as --exclude-quiet (I would say that this is mainly for scripts, so that a short option is not necessary).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003422) christos    2020-06-07 17:41	Added --exclude-quiet

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
161	[file] General	minor	always	2020-05-16 20:39	2020-05-31 10:48
Reporter:	pombredanne	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	feedback	Product Version:	5.38
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Regression to report .tag Targa image files type
Description:	The attached targa/TGA images are detected as "data" and they used to be detected correctly in version 5.25 as Targa image data.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	Image1.tga (543 bytes) 2020-05-16 20:39 https://bugs.astron.com/file_download.php?file_id=140&type=bug Image2.tga (52 bytes) 2020-05-16 20:39 https://bugs.astron.com/file_download.php?file_id=141&type=bug

Notes
(0003420) christos    2020-05-31 10:48	These files appear to be truncated (too short to be targa files). In order to avoid conflicts, the magic in newer versions of file has been made to look further in the file (in this case in offset 0xa00 - 2 = 2558. Since the files are shorter than that, it fails.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
163	[file] General	major	always	2020-05-19 13:48	2020-05-31 00:11
Reporter:	pombredanne	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	feedback	Product Version:	5.38
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Build fails on mingw64
Description:	When trying to update the msys2.org package for file to 5.38, the build fails See the PR at https://github.com/msys2/MINGW-packages/pull/6495 and in particular the build log at https://dev.azure.com/msys2/mingw/_build/results?buildId=5178&view=logs&jobId=d025390b-1dd2-5eea-69df-6ceb0b9eeced&j=d025390b-1dd2-5eea-69df-6ceb0b9eeced&t=7bf27dc4-4036-5dcd-5905-ed58d9f24e1f I have also attached a local build log from running this in a Windows VM
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	mingw-w64-file-5.38-1-x86_64-build.log (39,979 bytes) 2020-05-19 13:48 https://bugs.astron.com/file_download.php?file_id=142&type=bug

Notes
(0003406) pombredanne    2020-05-19 13:51	Note that 5.37 builds and runs fine
(0003407) pombredanne    2020-05-19 21:51	Here is a likely patch solving the problem. I am testing this now: diff --git a/src/compress.c b/src/compress.c index 904c215..c82e84b 100644 --- a/src/compress.c +++ b/src/compress.c @@ -380,7 +380,7 @@  sread(int fd, void *buf, size_t n, int canbepipe __attribute__((__unused__)))  {     ssize_t rv; -#ifdef FIONREAD +#ifdef FIONREAD && !defined(__MINGW32__) && !defined(WIN32)     int t = 0;  #endif     size_t rn = n; @@ -388,7 +388,7 @@     if (fd == STDIN_FILENO)         goto nocheck;   -#ifdef FIONREAD +#ifdef FIONREAD && !defined(__MINGW32__) && !defined(WIN32)     if (canbepipe && (ioctl(fd, FIONREAD, &t) == -1 || t == 0)) {  #ifdef FD_ZERO         ssize_t cnt;
(0003408) pombredanne    2020-05-20 08:32	Actually this patch is wrong all the way. Ignore that
(0003409) pombredanne    2020-05-20 10:59	This patch is working and all tests pass on msys2. I am crafting a packaging patch too. diff --git a/src/compress.c b/src/compress.c index 904c215..a5fdbb0 100644 --- a/src/compress.c +++ b/src/compress.c @@ -380,7 +380,7 @@  sread(int fd, void *buf, size_t n, int canbepipe __attribute__((__unused__)))  {      ssize_t rv; -#ifdef FIONREAD +#if defined(FIONREAD) && !defined(__MINGW32__) && !defined(WIN32)      int t = 0;  #endif      size_t rn = n; @@ -388,7 +388,7 @@      if (fd == STDIN_FILENO)          goto nocheck;   -#ifdef FIONREAD +#if defined(FIONREAD) && !defined(__MINGW32__) && !defined(WIN32)      if (canbepipe && (ioctl(fd, FIONREAD, &t) == -1 || t == 0)) {  #ifdef FD_ZERO          ssize_t cnt;
(0003410) pombredanne    2020-05-20 11:54	FWIW the PR at https://github.com/msys2/MINGW-packages/pull/6495 and all tests now pass on win32 and win64 when built with msys2
(0003411) pombredanne    2020-05-20 15:57	And FYI that PR has been accepted and merged there https://github.com/msys2/MINGW-packages/pull/6495
(0003419) christos    2020-05-31 00:11	Can you try what I commited in compress.c and file.h just now? /p/file/cvsroot/file/src/compress.c,v <-- compress.c new revision: 1.127; previous revision: 1.126 /p/file/cvsroot/file/src/file.h,v <-- file.h new revision: 1.217; previous revision: 1.216

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
160	[file] General	feature	always	2020-05-15 14:51	2020-05-30 23:58
Reporter:	rurban	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.38
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.39
		Target Version:
Summary:	Add latest AutoCAD DWG magic for r2018
Description:	Attached patch adds support for the current AutoCAD DWG format, used since 2018. AC1027 DWG AutoDesk AutoCAD 2013-2017 AC1032 DWG AutoDesk AutoCAD 2018/2019 I'm the GNU LibreDWG maintainer.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	cad.patch (482 bytes) 2020-05-15 14:51 https://bugs.astron.com/file_download.php?file_id=139&type=bug

Notes
(0003418) christos    2020-05-30 23:58	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
159	[file] General	crash	always	2020-04-28 22:07	2020-05-30 23:56
Reporter:	Lambda	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.38
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.39
		Target Version:
Summary:	Missing seccomp whitelist entry for getpid()
Description:	file_pipe2file() creates a new temporary file using mktemp()/mkstemp(), which use getpid() internally (at least in the glibc implementation). If seccomp support is enabled, the program crashes when this syscall is attempted to be used.
Tags:
Steps To Reproduce:	$ file --version file-5.38 magic file from /usr/share/file/misc/magic seccomp support included glibc 2.31 A rare case of justified cat abuse can be employed to demonstrate the crash in file_pipe2file() (which is currently only used in file_tryelf()): $ cat /bin/file | file - Bad system call
Additional Information:
Attached Files:

Notes
(0003417) christos    2020-05-30 23:56	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
158	[file] General	feature	always	2020-04-19 16:24	2020-05-30 23:53
Reporter:	Sembiance	Platform:
Assigned To:	christos	OS:
Priority:	low	OS Version:
Status:	resolved	Product Version:	5.38
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.39
		Target Version:
Summary:	Classification of pcxlib files
Description:	pcxlib is an old compression format back in the MS-DOS days. libmagic currently classifies these files as 'data' Information about the format can be found here: http://www.shikadi.net/moddingwiki/PCX_Library These files usually end in .PCL. I've attached a magic file that correctly identifies the file and also a test file. Could this format be incorporated into libmagic? This is my first time contributing to libmagic and as such my attached magic file might not be as awesome as it could be (like detection of version for example).
Tags:	magic
Steps To Reproduce:
Additional Information:
Attached Files:	POKER.PCL (101,558 bytes) 2020-04-19 16:24 https://bugs.astron.com/file_download.php?file_id=137&type=bug pcxlib-magic (131 bytes) 2020-04-19 16:24 https://bugs.astron.com/file_download.php?file_id=138&type=bug

Notes
(0003416) christos    2020-05-30 23:53	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
154	[file] General	feature	always	2020-04-05 17:32	2020-05-30 23:49
Reporter:	giovariot	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.37
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.39
		Target Version:
Summary:	QTK File support missing
Description:	These files are recognized as data by file 5.37, installed by default on macOS. Here is their description. I attached 3 files: * image 7 is a Quicktake 100 high-resolution RAW file (can be opened with dcraw). First 12 bytes: "716B746B 00000008 0001C566" (qktk Åf) * image 2 is a Quicktake 100 low-resolution RAW file (can be opened with dcraw). First 12 bytes: "716B746B 00000004 000073E6" (qktksæ) * image 1 is a Quicktake 100 file, it has the same first 12 bytes as the high-resolution RAW file ("716B746B 00000008 0001C566" (qktk Åf)) but it cannot be opened neither by dcraw nor by graphicconverter on macOS, so I don't really know what it is.
Tags:	magic
Steps To Reproduce:	file <image.qtk>
Additional Information:
Attached Files:	Image 1 - 24-09-2000.qtk (116,076 bytes) 2020-04-05 17:32 https://bugs.astron.com/file_download.php?file_id=131&type=bug Image 2 - 24-09-2000.qtk (32,082 bytes) 2020-04-05 17:32 https://bugs.astron.com/file_download.php?file_id=132&type=bug Image 7 - 24-09-2000.qtk (118,482 bytes) 2020-04-05 17:32 https://bugs.astron.com/file_download.php?file_id=133&type=bug

Notes
(0003415) christos    2020-05-30 23:49	Added, thanks. Image1 cannot be loaded by dcraw because the place where it reads the resolution seems to have 0's. Parts of the header are missing.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
156	[file] General	major	always	2020-04-19 10:05	2020-05-30 23:12
Reporter:	vinc17	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.38
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.39
		Target Version:
Summary:	misidentifies wikicode '''foo''' as troff
Description:	The wikicode '''foo''' (with 3 apostrophes) is misidentified as troff.
Tags:
Steps To Reproduce:	$ file - <<EOF '''foo''' EOF /dev/stdin: troff or preprocessor input, ASCII text
Additional Information:	The consequence is that such files become unreadable with "less".
Attached Files:

Notes
(0003413) christos    2020-05-30 23:12	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
157	[file] General	minor	always	2020-04-19 10:40	2020-05-30 23:06
Reporter:	vinc17	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.38
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Mis-detection of (perl-pod generated) troff files
Description:	troff files generated by Perl's pod2man are misdetected as ReStructuredText files.
Tags:
Steps To Reproduce:	$ echo '=head1 NAME' | pod2man | head -n 5 | file - /dev/stdin: ReStructuredText file, ASCII text Note about the first 5 lines: $ echo '=head1 NAME' | pod2man | head -n 5 .\" Automatically generated by Pod::Man 4.11 (Pod::Simple 3.35) .\" .\" Standard preamble: .\" ======================================================================== .de Sp \" Vertical space (when we can't use .PP)
Additional Information:	The Debian BTS has a similar bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949878 This is a regression: there was no such issue with file 5.35.
Attached Files:

Notes
(0003412) christos    2020-05-30 23:06	FIxed with: RCS file: /p/file/cvsroot/file/magic/Magdir/rst,v Working file: rst head: 1.3 branch: locks: strict access list: symbolic names:         FILE5_38: 1.2 keyword substitution: kv total revisions: 3; selected revisions: 3 description: ---------------------------- revision 1.3 date: 2020-04-26 21:50:36 -0400; author: christos; state: Exp; lines: +2 -2; commitid: KoQSLF01l8toQX5C; Fix escaping of periods

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
67	[file] General	minor	have not tried	2019-02-22 14:15	2020-04-16 16:00
Reporter:	valoq	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Fix bugtracker links on website
Description:	The official file website https://www.darwinsys.com/file/ have several broken links that point to gw.com which is not available. The bugtracker link points to http://bugs.gw.com/ which is also dead Please fix the linksto point to this bugtracker instead. This bugtracker is pretty hard to find otherwise.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003222) christos    2019-02-23 03:10	Ian Darwin fixed it.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
152	[file] General	major	always	2020-03-14 06:25	2020-03-21 16:49
Reporter:	pabs	Platform:	Linux
Assigned To:	christos	OS:	Debian
Priority:	normal	OS Version:	11 (bullseye)
Status:	resolved	Product Version:	5.38
Product Build:		Resolution:	reopened
Projection:	none
ETA:	none	Fixed in Version:	5.39
		Target Version:
Summary:	JPEG header detection: name use count (30) exceeded
Description:	Some JPEG files are successfully detected, including most headers but get an error "name use count (30) exceeded". The workaround for this issue is to either increase the name parameter or decrease the bytes parameter. In one test image, the extra info printed after the workaround is applied is "baseline, precision 8, 2335x1831, components 3". The error appears to occur after the Exif data is printed. As far as I can tell the error was caused by the change "use recursion to traverse the jpeg markers" to magic/Magdir/jpeg: # $File: jpeg,v 1.20 2014/08/05 07:32:31 christos Exp $ Here is the commit in the git mirror of CVS: https://github.com/file/file/commit/52400a1cf98e4cc252920239c291c66648c8fb3d For some reason this problem was masked before HOWMANY/FILE_BYTES_MAX were set to 1024*1024 in this change to src/file.h: + * @(#)$File: file.h,v 1.166 2015/01/09 19:28:32 christos Exp $ Here is the commit in the git mirror of CVS: https://github.com/file/file/commit/dd89d293fe62ca55542a5637e239b33404c58a8d
Tags:	recursion
Steps To Reproduce:	$ wget -q https://bugs.launchpad.net/ubuntu/+source/file/+bug/1717991/+attachment/4952354/+files/test.jpg $ file test.jpg $ file --parameter name=40 test.jpg $ file --parameter bytes=857393 test.jpg
Additional Information:	This issue has previously been reported to Debian, Ubuntu and Fedora: https://bugs.debian.org/928009 https://bugzilla.redhat.com/show_bug.cgi?id=1201630 https://bugs.launchpad.net/ubuntu/+source/file/+bug/1717991
Attached Files:

Notes
(0003394) christos    2020-03-20 16:06	Bumped from 30 to 50
(0003400) pabs    2020-03-21 00:41	Bumping the default recursion level seems like a workaround, is there no way to fix this without doing that?
(0003401) christos    2020-03-21 02:30	We could allow infinite recursion, but then one could construct malicious files that would either never terminate, or terminate after consuming a very large amount of resources.
(0003402) christos    2020-03-21 02:31	This solution (bumping the recursion level) allows us to handle most regular files without risking a DoS attack.
(0003403) pabs    2020-03-21 02:36	I see, thanks for the extra information. I guess the issue can be closed again.
(0003404) pabs    2020-03-21 02:56	FTR, this was fixed in this change:  * @(#)$File: file.h,v 1.214 2020/03/19 20:41:11 christos Exp $ Here is the commit in the git mirror of CVS: https://github.com/file/file/commit/df476c81d3e4171ec5d68fb259108ba875ae2caa

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
150	[file] General	feature	N/A	2020-03-02 00:46	2020-03-20 17:29
Reporter:	GerbilSoft	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.38
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.39
		Target Version:
Summary:	New magic: IPS and related patches, Nintendo Badge Arcade, Xbox 360, PVR, KTX, SquashFS fix
Description:	This batch of patches has the following: * IPS: Add a default file extension. * BPS, APS, UPS: Detect these patch formats. * Nintendo Badge arcade: Detect these files. * EXE: Added CPU type 0x1F2. (PowerPC, big-endian; used for Xbox 360) * STFS: Verify padding for MS-signed packages to prevent conflicts with some Nintendo DS ROM images. * PowerVR 3.0: Renamed from "PVR 3.0"; added big-endian support. * KTX: Added more S3TC enum values. * KTX2: Detect this image format. (up to date as of draft18) * SquashFS: Fix little-endian handling.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	file.2020-03-01.19-40.tar.gz (6,823 bytes) 2020-03-02 00:46 https://bugs.astron.com/file_download.php?file_id=127&type=bug 0012-images-KTX2-draft19-removed-zlib-and-LZMA-compressio.patch (1,088 bytes) 2020-03-06 03:57 https://bugs.astron.com/file_download.php?file_id=130&type=bug

Notes
(0003389) GerbilSoft    2020-03-06 03:57	Fix for KTX2: draft19 (released yesterday) removed zlib and LZMA supercompression options. Zstandard is now supercompression type 2.
(0003399) christos    2020-03-20 17:29	Patches applied, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
148	[file] General	minor	always	2020-02-23 05:09	2020-03-20 17:13
Reporter:	hlein	Platform:	amd64
Assigned To:	christos	OS:	Linux
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.38
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.39
		Target Version:
Summary:	PGP magic does not recognize files encrypted to Elgamal or ECC keys
Description:	...Long submission that took hours to write eaten by Mantis. tl;drewrite: file does not recognize files encrypted with Elgamal keys (the default for old-fashioned DSA sign-only keys). I'll attach a patch that makes file properly recognize files encrypted to Elgamal keys, for example: $ file elg* elg1024.pgp: PGP Elgamal encrypted session key - keyid: 833B4548 8802A9A6 Elgamal Encrypt-Only 1024b. elg1024_enconly.pgp: PGP Elgamal encrypted session key - keyid: 833B4548 8802A9A6 Elgamal Encrypt-Only 1024b. elg2048.pgp: PGP Elgamal encrypted session key - keyid: 12AFCC09 B6C9040B Elgamal Encrypt-Only 2048b. elg2048_enconly.pgp: PGP Elgamal encrypted session key - keyid: 12AFCC09 B6C9040B Elgamal Encrypt-Only 2048b. elg3072.pgp: PGP Elgamal encrypted session key - keyid: 213768B7 E0AC80E4 Elgamal Encrypt-Only 3072b. elg3072_enconly.pgp: PGP Elgamal encrypted session key - keyid: 213768B7 E0AC80E4 Elgamal Encrypt-Only 3072b.
Tags:
Steps To Reproduce:
Additional Information:	This is on top of the other patches to magic/Magdir/pgp I've submitted, although for once there might not actually be any overlap/collision.
Attached Files:	file-magic-pgp-elgamal.diff (1,300 bytes) 2020-02-23 05:09 https://bugs.astron.com/file_download.php?file_id=126&type=bug

Notes
(0003398) christos    2020-03-20 17:13	Patch applied, sorry you lost time with mantis... Do you know what's broken with it?

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
145	[file] General	minor	always	2020-02-22 01:38	2020-03-20 16:16
Reporter:	hlein	Platform:	amd64
Assigned To:	christos	OS:	Linux
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.38
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.39
		Target Version:
Summary:	Incorrect labels for PGP keys of 4096 and 8192 bytes
Description:	magic/Magdir/pgp contains rules for PGP files and prints the key size and keyid such as: # 1024b RSA encrypted data 0 string \x84\x8c\x03 PGP RSA encrypted session key - ... >11 byte 0x01 RSA (Encrypt or Sign) 1024b >11 byte 0x02 RSA Encrypt-Only 1024b Several entries have typoes in either the comment, or the output string, or both.
Tags:	magic
Steps To Reproduce:
Additional Information:	I'll attach a patch to fix these. Note that this diff is on top of the one I submitted for https://bugs.astron.com/view.php?id=144
Attached Files:	file-magic-pgp-keysizes.diff (788 bytes) 2020-02-22 01:38 https://bugs.astron.com/file_download.php?file_id=125&type=bug

Notes
(0003396) christos    2020-03-20 16:16	Patch applied, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
144	[file] General	minor	always	2020-02-22 01:27	2020-03-20 16:11
Reporter:	hlein	Platform:	amd64
Assigned To:	christos	OS:	Linux
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.38
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.39
		Target Version:
Summary:	PGP keyids are printed in the wrong byte order
Description:	Magdir/pgp includes rules like: # 1024b RSA encrypted data 0 string \x84\x8c\x03 PGP RSA encrypted session key - >3 lelong x keyid: %X >7 lelong x %X >11 byte 0x01 RSA (Encrypt or Sign) 1024b >11 byte 0x02 RSA Encrypt-Only 1024b ... # 2048b RSA encrypted data 0 string \x85\x01\x0c\x03 PGP RSA encrypted session key - >4 lelong x keyid: %X >8 lelong x %X ... I think all of these should be belong instead of lelong. Also, a keyid may begin with a zero, which is meaningful. So these %X's ought to be %08X's.
Tags:	magic
Steps To Reproduce:	1) (Optional) generate a test key. 2) List the key to use with its subkeys: $ gpg --list-keys --with-colons 5AB23C204B1829F3E33BBA37DBEA6F441E3DF797 tru::0:1582326417:1582758336:3:1:5 pub:u:2048:1:DBEA6F441E3DF797:1582326336:1582758336::u:::scESC::::::23::0: fpr:::::::::5AB23C204B1829F3E33BBA37DBEA6F441E3DF797: uid:u::::1582326336::F659DAB0221BFC1C737B3BF9C9CD9292ECDDEED7::Test RSA/RSA Key::::::::::0: sub:u:2048:1:577B8DB374A47B2B:1582326336:1582758336:::::e::::::23: fpr:::::::::C161291BD41A414C8B16CF66577B8DB374A47B2B: 3) Note the keyid of the subkey: 577B8DB3 74A47B2B 4) Use that key to encrypt+sign a test file to itself: $ echo test | gpg --local-user 5AB23C204B1829F3E33BBA37DBEA6F441E3DF797 -se -r 5AB23C204B1829F3E33BBA37DBEA6F441E3DF797 -o test.pgp 5) Use file to check the file: $ file test.pgp test.pgp: PGP RSA encrypted session key - keyid: B38D7B57 2B7BA474 RSA (Encrypt or Sign) 2048b . 6) Observe that 577B8DB3 74A47B2B != B38D7B57 2B7BA474 7) Use gpg --list-packets to see what it has to say about the recipient key: $ gpg --list-packets test.pgp gpg: encrypted with 2048-bit RSA key, ID 577B8DB374A47B2B, created 2020-02-21       "Test RSA/RSA Key" # off=0 ctb=85 tag=1 hlen=3 plen=268 :pubkey enc packet: version 3, algo 1, keyid 577B8DB374A47B2B 8) Use hexdump -C to look at the raw bytes: $ hexdump -C test.pgp | head -n1 00000000 85 01 0c 03 57 7b 8d b3 74 a4 7b 2b 01 07 ff 46 |....W{..t.{+...F|
Additional Information:	AFAIK just switching all of the lelong's to belong's in Magdir/pgp is the right thing to do. With that: $ file test.pgp test.pgp: PGP RSA encrypted session key - keyid: 577B8DB3 74A47B2B RSA (Encrypt or Sign) 2048b . I'll attach a patch to make those changes, and also switch from %X to %08X.
Attached Files:	file-magic-pgp-keyid-printing.diff (1,641 bytes) 2020-02-22 01:27 https://bugs.astron.com/file_download.php?file_id=124&type=bug

Notes
(0003395) christos    2020-03-20 16:11	Patch applied, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
142	[tcsh] General	major	sometimes	2020-02-14 14:32	2020-02-19 14:06
Reporter:	bitstreamout	Platform:	x86_64
Assigned To:	christos	OS:	linux
Priority:	normal	OS Version:
Status:	assigned	Product Version:	6.22.02
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Dot locking sometimes does block after reboot
Description:	During reboot it happens sometimes that one of my open tcsh sesssions does not get enough time to write out history and got killed by systemd before the dot lock file had been removed. It would be a a solution to combine the dot locking method with fcntl(F_SETLKW/F_UNLCK) as this does work over NFS at least for Linux. This also would allow to avoid polling due waiting on F_SETLKW ...
Tags:
Steps To Reproduce:	Open several tcsh sessions, do some work therein, and reboot
Additional Information:
Attached Files:	tcsh-6.22.02-local-dotlock.dif (1,861 bytes) 2020-02-18 08:06 https://bugs.astron.com/file_download.php?file_id=122&type=bug tcsh-6.22.02-local-dotlock-2.dif (2,594 bytes) 2020-02-19 10:05 https://bugs.astron.com/file_download.php?file_id=123&type=bug

Notes
(0003371) christos    2020-02-16 16:15	Perhaps it is better to give up with a message to the user instead of getting stuck... I don't want to add more complexity to the locking. The point of dotlock is to not use the fcntl() based in the first place which is even less reliable over NFS...
(0003374) bitstreamout    2020-02-17 10:05	Hmmm ... on Linux based systems itz is possible to determine the process which holds the file descriptor. But this requires to parse /proc/ ... on the other hand most modern Linux systems have a tmpfs based /dev/shm worls writable and sticky directory which not only tmpfs but also a local file system. Besdide this : I had used some years a patch set from redhat with fcntl() based locking which never had shown problems over NFS ... only the porting to the next tcsh version had become complicated and fragile with increasing version number.
(0003375) christos    2020-02-17 17:53    (Last edited: 2020-02-17 17:54)	Yes, but remember tcsh runs on other OS's including windows... And this is a corner case that does not usually happen. Doesn't systemd have a way to increase the grace time it waits before killing the processes?
(0003376) bitstreamout    2020-02-18 08:06	Not really as the most tcsh process do poll by sleeping within usleep() ... using F_SETLKW would avoid this but requires interrupt handling. Currently I use a workaround, which is use /dev/shm as this file system is always fresh because it is tmpfs based
(0003377) christos    2020-02-18 20:20	What happens when the home directory is mounted over NFS and shared between different hosts? How will the other systems see the tmpfs lock? Let's try to treat the cause (systemd killing tcsh too quickly) instead of the symptoms (tcsh leaving a stray lock file around because it got kill -9'ed).
(0003379) bitstreamout    2020-02-19 07:54	Good point, personal I use different histories for different hosts. The fcntl() method had worked here over years without any problems, that means I had never seen any problems nor had got any bug reports. Maybe this is also Linux specific ... only rebooted (linux based) NFS servers may cause that a lock gets lost. For this a local tcsh has to write out its history at the same time as the NFS server is rebooted
(0003380) bitstreamout    2020-02-19 10:05	in create_exclusive(): How about open the fname after link(path, fname) and then unlink(fname)? As long as the process hold the file descriptor the dot lock file i That means that if the process gets kill-9'ed the file will disapear with the last open file descriptor
(0003381) christos    2020-02-19 13:43	Then locking does not work. Another process can do the same (on the same or a different machine). This is the whole idea behind dot locking: that you can only touch the file once you've established you are the owner (by creating the link and making sure that the link count is 2).
(0003382) bitstreamout    2020-02-19 14:00	Hmm ... here it seems to work at least on the same machine ``` openat(AT_FDCWD, "/suse/werner/.tcsh/.noether.d574", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_SYNC, 0200) = 3 close(3) = 0 link("/suse/werner/.tcsh/.noether.d574", "/suse/werner/.tcsh/werner@noether.lock") = -1 EEXIST (File exists) unlink("/suse/werner/.tcsh/.noether.d574") = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 nanosleep({tv_sec=0, tv_nsec=100000000}, NULL) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT QUIT TERM CHLD TSTP TTIN TTOU], [], 8) = 0 uname({sysname="Linux", nodename="noether", ...}) = 0 getpid() = 11676 openat(AT_FDCWD, "/suse/werner/.tcsh/.noether.2be3e", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_SYNC, 0200) = 3 close(3) = 0 link("/suse/werner/.tcsh/.noether.2be3e", "/suse/werner/.tcsh/werner@noether.lock") = 0 openat(AT_FDCWD, "/suse/werner/.tcsh/werner@noether.lock", O_WRONLY|O_EXCL|O_SYNC) = 3 unlink("/suse/werner/.tcsh/werner@noether.lock") = 0 stat("/suse/werner/.tcsh/.noether.2be3e", {st_mode=S_IFREG|0200, st_size=0, ...}) = 0 unlink("/suse/werner/.tcsh/.noether.2be3e") = 0 ``` ``` openat(AT_FDCWD, "/suse/werner/.tcsh/.noether.dc5c", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_SYNC, 0200) = 3 close(3) = 0 link("/suse/werner/.tcsh/.noether.dc5c", "/suse/werner/.tcsh/werner@noether.lock") = 0 openat(AT_FDCWD, "/suse/werner/.tcsh/werner@noether.lock", O_WRONLY|O_EXCL|O_SYNC) = 3 unlink("/suse/werner/.tcsh/werner@noether.lock") = 0 stat("/suse/werner/.tcsh/.noether.dc5c", {st_mode=S_IFREG|0200, st_size=0, ...}) = 0 unlink("/suse/werner/.tcsh/.noether.dc5c") = 0 ```
(0003383) christos    2020-02-19 14:06	The point is that at the time you remove the lock there could be another process (on a different machine perhaps) who owns the lock and is currently writing the file. The lock is a sign that the file is busy. If you remove it indiscriminately there is no point in creating it in the first place.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
143	[file] General	minor	always	2020-02-14 15:36	2020-02-16 20:46
Reporter:	tuxick	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.39
		Target Version:
Summary:	X.509 DER certificate not recognized
Description:	X.509 DER certificate not recognized , signature would be 0x3028
Tags:
Steps To Reproduce:
Additional Information:	Found this missing on current centos, rhel, debian and ubuntu
Attached Files:	test.der (716 bytes) 2020-02-16 16:47 https://bugs.astron.com/file_download.php?file_id=121&type=bug

Notes
(0003369) christos    2020-02-16 15:55	Can you attach a copy of the cert?
(0003372) tuxick    2020-02-16 16:47	This is result of "openssl x509 -in test.crt -outform der -out test.der" I don't know why this is done, but i was send such cert to install, and it had wrong extension
(0003373) christos    2020-02-16 20:46	Fixed, thanks

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
141	[file] General	major	always	2020-02-13 22:42	2020-02-16 16:09
Reporter:	Andreas	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.38
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.39
		Target Version:
Summary:	Mpeg videos detected as image/x-tga
Description:	Several video files are detected as image/x-tga instead of video/mpeg in the latest version.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	arthur.mpg (1,789,952 bytes) 2020-02-13 22:42 https://bugs.astron.com/file_download.php?file_id=111&type=bug arthurDVDNTSCHiQ.vob (1,429,504 bytes) 2020-02-13 22:42 https://bugs.astron.com/file_download.php?file_id=112&type=bug arthurDVDPalStrdQ.vob (1,335,296 bytes) 2020-02-13 22:42 https://bugs.astron.com/file_download.php?file_id=113&type=bug arthurVideoOnly.vob (1,249,280 bytes) 2020-02-13 22:42 https://bugs.astron.com/file_download.php?file_id=114&type=bug

Notes
(0003370) christos    2020-02-16 16:09	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
140	[file] General	minor	always	2020-02-04 23:32	2020-02-16 15:53
Reporter:	gockelhahn	Platform:	x86_64
Assigned To:	christos	OS:	arch linux
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.38
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.39
		Target Version:
Summary:	hit asserts send SIGABRT leading to unplanned exit
Description:	fuzzing with stock afl found some binary magic files, which will run into code asserts, which will lead to an abrupt:     Aborted (core dumped)     echo $?     134 when seccomp is compiled in, we get:     Bad system call     echo $?     159 not sure if you like the output or if you want to exit the program with a more userfriendly message?
Tags:	magic
Steps To Reproduce:	git clone https://github.com/file/file.git     cd file     export CFLAGS="-g -fsanitize=address -fno-omit-frame-pointer"     autoreconf -i     ./configure [--disable-libseccomp]     make all     ./src/.libs/lt-file -m ~/test3.mgc /etc/services
Additional Information:	master @ 85b214cd422dd2538800c8b6d6e6c383d9ee17bf
Attached Files:	test3.mgc (6 bytes) 2020-02-04 23:32 https://bugs.astron.com/file_download.php?file_id=110&type=bug crash.tar.gz (553 bytes) 2020-02-15 21:36 https://bugs.astron.com/file_download.php?file_id=120&type=bug

Notes
(0003357) christos    2020-02-13 17:21	Fixed, thanks!
(0003366) gockelhahn    2020-02-15 21:34	i still have some sigabrt magics, which still crash
(0003367) gockelhahn    2020-02-15 21:36	see new attachment ... thanks for caring!
(0003368) christos    2020-02-16 15:53	Fixed, these are all the same issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
128	[file] General	major	sometimes	2020-01-10 10:40	2020-02-15 01:02
Reporter:	roberto beltrami	Platform:	intel
Assigned To:	christos	OS:	windows
Priority:	high	OS Version:	all
Status:	resolved	Product Version:	5.38
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.39
		Target Version:
Summary:	wrong detection of .pnx data files
Description:	.pnx are data files for our cad/cam system. I attacched 3 files, good.pnx is correctly detected as 'data' while err1 and err2 are detected as '68k Blit mpx/mux executable'. can you solve this? many thanks
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	good.pnx (30,370 bytes) 2020-01-10 10:40 https://bugs.astron.com/file_download.php?file_id=94&type=bug err2.PNX (193,278 bytes) 2020-01-10 10:40 https://bugs.astron.com/file_download.php?file_id=95&type=bug err1.pnx (128,654 bytes) 2020-01-10 10:40 https://bugs.astron.com/file_download.php?file_id=96&type=bug

Notes
(0003345) christos    2020-01-17 17:49	What's the CAD system name? Did you develop it internally or is it a commercial product? Where is the file format described?
(0003347) roberto beltrami    2020-01-20 08:54	The CAD system is NAXOS and we develop it internally. The file format is reserved. Most data is compressed and encrypted, so we don't have control over the byte sequences generated
(0003355) roberto beltrami    2020-02-13 07:40	no news?
(0003359) christos    2020-02-13 20:39	Sorry, I've been busy. If there is no standard header in your files and they can contain any byte sequence, file(1) can't recognize them and different pnx files can will end up producing spurious matches. This cannot be fixed until the system produces files that have standard header...
(0003362) roberto beltrami    2020-02-14 09:19	I'm sure you understand that we cannot change our format just because your software detect as '68k Blit mpx/mux executable' a file that is something else. If it can help you, starting from offset 4 you find a 16bytes string (zero terminated) with letter P followed by the sw version that produced the file. for example, 'P19.1607.1627.0' or 'P20.1629.1631.0 '. please let me know best regards roberto
(0003363) roberto beltrami    2020-02-14 09:22	BTW, the numbers often change because we release new versions almost every month. so you should rely on the structure of the string Pxx.xxxx.xxxx.x and not the exact numbers
(0003364) roberto beltrami    2020-02-14 09:23	x are always 0-9, no letters nor special chars
(0003365) christos    2020-02-15 01:02	Well, that pattern can be used as a magic number and I've already added it! The next version of the program will recognize PNX files: [8:02pm] 348>./file -m ../magic/magic.mgc *.pnx err1.pnx: NAXOS CAD System file from version P19.1629.1630.0 err2.pnx: NAXOS CAD System file from version P19.1607.1628.0 good.pnx: NAXOS CAD System file from version P19.1607.1615.0

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
139	[file] General	minor	always	2020-02-04 22:49	2020-02-13 18:10
Reporter:	gockelhahn	Platform:	x86_64
Assigned To:	christos	OS:	arch linux
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.38
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.39
		Target Version:
Summary:	massive memory usage (leak!?) for small crafted magic files
Description:	fuzzing with stock afl found some plain magic files, taking a lot of memory and time to produce a result (mostly white trash)
Tags:	magic
Steps To Reproduce:	git clone https://github.com/file/file.git     cd file     export CFLAGS="-g -fsanitize=address -fno-omit-frame-pointer"     autoreconf -i     ./configure --disable-libseccomp     make all     ./src/.libs/lt-file -m ~/test2_1 /etc/services
Additional Information:	master @ 85b214cd422dd2538800c8b6d6e6c383d9ee17bf
Attached Files:	test2_5 (58 bytes) 2020-02-04 22:49 https://bugs.astron.com/file_download.php?file_id=105&type=bug test2_4 (90 bytes) 2020-02-04 22:49 https://bugs.astron.com/file_download.php?file_id=106&type=bug test2_3 (59 bytes) 2020-02-04 22:49 https://bugs.astron.com/file_download.php?file_id=107&type=bug test2_2 (59 bytes) 2020-02-04 22:49 https://bugs.astron.com/file_download.php?file_id=108&type=bug test2_1 (59 bytes) 2020-02-04 22:49 https://bugs.astron.com/file_download.php?file_id=109&type=bug test2_6 (57 bytes) 2020-02-04 22:49 https://bugs.astron.com/file_download.php?file_id=104&type=bug

Notes
(0003358) christos    2020-02-13 18:10	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
138	[file] General	crash	always	2020-02-04 22:30	2020-02-13 17:09
Reporter:	gockelhahn	Platform:	x86_64
Assigned To:	christos	OS:	arch linux
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.38
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.39
		Target Version:
Summary:	crash (heap-buffer-overflow with) with crafted binary magic file
Description:	fuzzing with stock afl found this:     ==14786==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60f000000030 at pc 0x7f0c5ad0fd41 bp 0x7ffe3ec50b20 sp 0x7ffe3ec50b10     READ of size 4 at 0x60f000000030 thread T0         #0 0x7f0c5ad0fd40 in mget /home/build/file/src/softmagic.c:1701         0000001 0x7f0c5ad0453a in match /home/build/file/src/softmagic.c:244         0000002 0x7f0c5ad03d37 in file_softmagic /home/build/file/src/softmagic.c:134         0000003 0x7f0c5ad14551 in file_ascmagic_with_encoding /home/build/file/src/ascmagic.c:156         0000004 0x7f0c5ad1405e in file_ascmagic /home/build/file/src/ascmagic.c:95         0000005 0x7f0c5ad2ee56 in file_buffer /home/build/file/src/funcs.c:352         0000006 0x7f0c5acf064c in file_or_fd /home/build/file/src/magic.c:514         0000007 0x7f0c5aceff2f in magic_file /home/build/file/src/magic.c:398         0000008 0x563f499a5a9c in process /home/build/file/src/file.c:542         #9 0x563f499a4f51 in main /home/build/file/src/file.c:413         0000010 0x7f0c5aae5152 in __libc_start_main (/usr/lib/libc.so.6+0x27152)         0000011 0x563f499a43cd in _start (/home/build/file/src/.libs/lt-file+0x53cd)     0x60f000000030 is located 16 bytes to the left of 168-byte region [0x60f000000040,0x60f0000000e8)     allocated by thread T0 here:         #0 0x7f0c5ae77aca in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:144         0000001 0x7f0c5aaf07de in _nl_intern_locale_data (/usr/lib/libc.so.6+0x327de)     SUMMARY: AddressSanitizer: heap-buffer-overflow /home/build/file/src/softmagic.c:1701 in mget     Shadow bytes around the buggy address:     0x0c1e7fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     0x0c1e7fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     0x0c1e7fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     0x0c1e7fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     0x0c1e7fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     =>0x0c1e7fff8000: fa fa fa fa fa fa[fa]fa 00 00 00 00 00 00 00 00     0x0c1e7fff8010: 00 00 00 00 00 00 00 00 00 00 00 00 00 fa fa fa     0x0c1e7fff8020: fa fa fa fa fa fa 00 00 00 00 00 00 00 00 00 00     0x0c1e7fff8030: 00 00 00 00 00 00 00 00 00 00 00 03 fa fa fa fa     0x0c1e7fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa     0x0c1e7fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa     Shadow byte legend (one shadow byte represents 8 application bytes):     Addressable: 00     Partially addressable: 01 02 03 04 05 06 07     Heap left redzone: fa     Freed heap region: fd     Stack left redzone: f1     Stack mid redzone: f2     Stack right redzone: f3     Stack after return: f5     Stack use after scope: f8     Global redzone: f9     Global init order: f6     Poisoned by user: f7     Container overflow: fc     Array cookie: ac     Intra object redzone: bb     ASan internal: fe     Left alloca redzone: ca     Right alloca redzone: cb     Shadow gap: cc     ==14786==ABORTING
Tags:	magic
Steps To Reproduce:	git clone https://github.com/file/file.git     cd file     export CFLAGS="-g -fsanitize=address -fno-omit-frame-pointer"     autoreconf -i     ./configure --disable-libseccomp     make all     ./src/.libs/lt-file -m ~/test.mgc /etc/services
Additional Information:	master @ 85b214cd422dd2538800c8b6d6e6c383d9ee17bf
Attached Files:	test.mgc (752 bytes) 2020-02-04 22:30 https://bugs.astron.com/file_download.php?file_id=103&type=bug

Notes
(0003356) christos    2020-02-13 17:09	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
136	[file] General	major	always	2020-01-31 19:37	2020-02-12 22:31
Reporter:	Fabrice	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.38
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.39
		Target Version:
Summary:	Static build failure (can be fixed by adding libmagic.pc)
Description:	libmagic can optionally depends on xz (for lzma) or bzip2 since version 5.38 and https://github.com/file/file/commit/b259a07ea95827f565faa20f0316e5b2704064f7 so add libmagic.pc so package (such as gerbera) that links with libmagic will be able to use pkg-config to retrieve those static dependencies For example, this will avoid the following build failure: [100%] Linking CXX executable gerbera /home/br-user/autobuild/run/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabi/8.3.0/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld: /home/br-user/autobuild/run/instance-0/output-1/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libmagic.a(compress.o): in function `uncompressbuf': compress.c:(.text+0x69c): undefined reference to `BZ2_bzDecompressInit' /home/br-user/autobuild/run/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabi/8.3.0/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld: compress.c:(.text+0x710): undefined reference to `BZ2_bzDecompress' /home/br-user/autobuild/run/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabi/8.3.0/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld: compress.c:(.text+0x730): undefined reference to `BZ2_bzDecompressEnd' /home/br-user/autobuild/run/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabi/8.3.0/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld: compress.c:(.text+0x7bc): undefined reference to `lzma_auto_decoder' /home/br-user/autobuild/run/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabi/8.3.0/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld: compress.c:(.text+0x828): undefined reference to `lzma_code' /home/br-user/autobuild/run/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabi/8.3.0/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld: compress.c:(.text+0x848): undefined reference to `lzma_end' Fixes:  - http://autobuild.buildroot.org/results/37b1ef54dc41100689f311fbc31fc9300dc6ae63
Tags:
Steps To Reproduce:
Additional Information:	You'll find attached a patch that adds libmagic.pc
Attached Files:	0001-Add-libmagic.pc.patch (3,860 bytes) 2020-01-31 19:37 https://bugs.astron.com/file_download.php?file_id=102&type=bug

Notes
(0003353) christos    2020-02-12 22:31	Committed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
133	[file] General	minor	always	2020-01-24 15:36	2020-02-12 22:18
Reporter:	eschwartz	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.38
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.39
		Target Version:
Summary:	file 5.38 removed support for detecting pie executable
Description:	What is the purpose of commit https://github.com/file/file/commit/d653309de04ed10fdeda79f2c6ca7a7e96e122f1?
Tags:	magic
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003348) eschwartz    2020-01-24 20:39	It was pointed out in this downstream bug report ( https://bugs.archlinux.org/task/65256 ) that the intention may be to unify pie-executable and shared libraries. "the unification makes sense as +x is not a appropriate way to detect if its a shared library or an application, which way around it should be is a matter of choice but technically PIE executables are not any different, except some subtile ways in relative references." I did not read this into the commit message which was used to describe the change, so forgive me if I've misunderstood the situation. But if there was any intent to heuristically detect pie executables vs. shared libraries, then at the moment it does not seem to be happening in actuality.a
(0003351) christos    2020-02-12 22:18	You are right, I put it back.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
132	[file] General	minor	always	2020-01-22 13:44	2020-02-12 22:13
Reporter:	tumik	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.35
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.39
		Target Version:
Summary:	Many source files get recognized as "TI-XX Graphing Calculator (FLASH)"
Description:	The detection for "TI-XX Graphing Calculator (FLASH)" seems way too broad, with only checking the word "Advanced" at offset of 0x16. I've run into many files, for example source code files, which start with an copyright of a company beginning with "Advanced". An example: // Copyright (c) 2019 Advanced RISC Machines Ltd. All Rights Reserved. This file gets incorrectly tagged as "TI-XX Graphing Calculator (FLASH)".
Tags:
Steps To Reproduce:	$ echo "// Copyright (c) 2019 Advanced" > test $ file test test: TI-XX Graphing Calculator (FLASH) $
Additional Information:
Attached Files:

Notes
(0003350) christos    2020-02-12 22:13	commented out, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
131	[file] General	minor	always	2020-01-14 03:35	2020-01-17 21:29
Reporter:	david_keeffe	Platform:	RHEL 7
Assigned To:	christos	OS:	Linux
Priority:	normal	OS Version:	3.10.0
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	The magic file in File 5.11 reports some HTML as C++
Description:	If an HTML file has the word 'class' starting at the beginning of a line, file reports it as C++. This appears often in HTML output by Microsoft Word: text between <...> is line wrapped. The issue seems to be that the distributed magic file raises the strength of C++ constructs and/or C++ appears before HTML.
Tags:
Steps To Reproduce:	On RHEL 7: file /path/to/file
Additional Information:
Attached Files:

Notes
(0003343) christos    2020-01-17 17:26	Can you please share an example?
(0003346) david_keeffe    2020-01-17 21:29	I think the problem has been fixed in a newer version - testing on a Mac gives expected results. I think this bug needs raising with RedHat since they choose to use much older version of 'file'. Idril:~ david$ cat small.html <html> <body> <div class='xxx'>      Hello World </div> </body> </html> Idril:~ david$ file small.html small.html: HTML document text, ASCII text Idril:~ david$ cat small-c.html <html> <body> <div class='xxx'>      Hello World </div> </body> </html> Idril:~ david$ file small-c.html small-c.html: HTML document text, ASCII text Idril:~ david$ file -v file-5.33 magic file from /usr/share/file/magic

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
129	[file] General	feature	N/A	2020-01-10 16:26	2020-01-17 17:40
Reporter:	Fabian	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.39
		Target Version:
Summary:	Classification of SYLK Files
Description:	SYLK is an old Microsoft file format for spread sheets [1]. It recently got some attention as it can be used to weaponise documents as it can run macros [2]. It would be great to be able to classify SYLK documents with libmagic. This could be used to filter SYLK documents by true content. Information about the file format can be found on [3]. Summary: * SYLK files contain line-based operations which each start on a new line * Start with "ID". Possibly followed by ";P" but that is not mandatory. * Macros are enabled with the "O;E" operation. They are also enabled in combination with other options like "O;P;E". * Macros can be automatically executed with auto_open string. * The operations like "ID" "O;E" are case-sensitive. "auto_open" is case insensitive. Do you support adding SYLK classification to Libmagic? Just basing the classification on a file starting with "ID" may cause false positives. The classification could be made more precise by also checking whether support for macros is enabled. This would mean the classification is not for SYLK files, but SYLK files with macros. Two test files have been attached. [1] https://en.wikipedia.org/wiki/SYmbolic_LinK_(SYLK) [2] https://outflank.nl/blog/2019/10/30/abusing-the-sylk-file-format/ [3] https://outflank.nl/upload/sylksum.txt
Tags:	magic
Steps To Reproduce:
Additional Information:
Attached Files:	sylk_test.slk (101 bytes) 2020-01-10 16:26 https://bugs.astron.com/file_download.php?file_id=97&type=bug sylk_test_obfuscated.slk (99 bytes) 2020-01-10 16:26 https://bugs.astron.com/file_download.php?file_id=98&type=bug

Notes
(0003344) christos    2020-01-17 17:40	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
130	[file] General	minor	always	2020-01-11 11:07	2020-01-17 17:20
Reporter:	tobias	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.38
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.39
		Target Version:
Summary:	sandbox blocks required TCGETS on console with glibc
Description:	Calling file from a terminal like tty0, i.e. not from a terminal emulator or multiplexer, just plain old /bin/bash as login shell, results in a bad system call. The problem is that glibc on a terminal calls ioctl TCGETS, which is not allowed by sandbox. I have attached a patch that fixes the issue.
Tags:
Steps To Reproduce:	1. Log in on a tty, do not use a virtual terminal emulator like xterm etc. 2. Call "file /" or anything else which accesses the file system 3. You see "Bad system call" 4. Call "strace file /" and notice that ioctl(1, TCGETS, ...) = ?" gets interrupted
Additional Information:	I'm using: - x86_64 - linux 5.4.10 - glibc 2.30 - libseccomp 2.4.2 - file 5.38 (compiled with libseccomp support)
Attached Files:	file-5.38-seccomp.patch (431 bytes) 2020-01-11 11:07 https://bugs.astron.com/file_download.php?file_id=99&type=bug

Notes
(0003342) christos    2020-01-17 17:20	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
126	[file] General	minor	have not tried	2019-12-17 14:50	2020-01-06 18:23
Reporter:	bodqhrohro	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	feedback	Product Version:	5.37
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	ASF, WMA and WMV are all detected as "Microsoft ASF"
Description:	@bq:16:48:02:/tmp/dl$ ffprobe -hide_banner loudspeaker.asf Input #0, asf, from 'loudspeaker.asf':   Metadata:     major_brand : isom     minor_version : 512     compatible_brands: isomiso2avc1mp41     encoder : Lavf58.29.100   Duration: 00:00:55.86, start: 0.000000, bitrate: 480 kb/s     Stream #0:0: Video: msmpeg4v3 (MP43 / 0x3334504D), yuv420p, 640x480, SAR 1:1 DAR 4:3, 23.98 fps, 23.98 tbr, 1k tbn, 1k tbc     Stream #0:1: Audio: wmav2 (a[1][0][0] / 0x0161), 44100 Hz, 2 channels, fltp, 128 kb/s @bq:16:48:13:/tmp/dl$ ffprobe -hide_banner loudspeaker.wma Input #0, asf, from 'loudspeaker.wma':   Metadata:     major_brand : isom     minor_version : 512     compatible_brands: isomiso2avc1mp41     encoder : Lavf58.29.100   Duration: 00:00:55.69, start: 0.000000, bitrate: 136 kb/s     Stream #0:0: Audio: wmav2 (a[1][0][0] / 0x0161), 44100 Hz, 2 channels, fltp, 128 kb/s @bq:16:48:15:/tmp/dl$ ffprobe -hide_banner loudspeaker.wmv Input #0, asf, from 'loudspeaker.wmv':   Metadata:     major_brand : isom     minor_version : 512     compatible_brands: isomiso2avc1mp41     encoder : Lavf58.29.100   Duration: 00:00:55.90, start: 0.000000, bitrate: 476 kb/s     Stream #0:0: Video: msmpeg4v3 (MP43 / 0x3334504D), yuv420p, 640x480, SAR 1:1 DAR 4:3, 23.98 fps, 23.98 tbr, 1k tbn, 1k tbc     Stream #0:1: Audio: wmav2 (a[1][0][0] / 0x0161), 44100 Hz, 2 channels, fltp, 128 kb/s @bq:16:48:18:/tmp/dl$ file loudspeaker.asf loudspeaker.asf: Microsoft ASF @bq:16:48:24:/tmp/dl$ file loudspeaker.wma loudspeaker.wma: Microsoft ASF @bq:16:48:25:/tmp/dl$ file loudspeaker.wmv loudspeaker.wmv: Microsoft ASF ASF and WMV may be the same, but WMA should definitely be printed exactly, as it's important if a file contains a video track or only audio.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003341) christos    2020-01-06 18:23	There is better detection for ASF contents now, but it still needs work.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
90	[file] General	feature	N/A	2019-07-04 19:12	2019-12-31 03:12
Reporter:	Pysis	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:	5.37
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Adds Nintendo Console Wii U/Switch file formats
Description:	Adds header detailed output support for these formats:  - Yaz0  - BYAML  - BFRES  - BLWP  - STAT  - BARS  - BFSAR  - SARC Lightly Documents these formats "clearinghouse" style:  - BTSND  - RPL/RPX  - BFMA  - (Non-archive) ARC Tested with local sample files and Bats-core tests:  - tests/data/A-1.00.autoplacement_forbid.agstats  - tests/data/MapTex_A-0_0.bfres  - tests/data/yaz0.sarc  - tests/data/AkkareLabBgm.bars  - tests/data/_DistanceView_Dynamic.byml  - tests/data/DummySound.bfsar  - tests/data/yaz0/_DistanceView_TeraTree.sblwp  - tests/data/yaz0/AncientArrow.sbitemico  - tests/data/yaz0/MapOpen_00.sbmapopen  - tests/data/yaz0/MapTex_A-0_0.sbmaptex  - tests/data/yaz0/5000000000.grass.extm.sstera  - tests/data/yaz0/_DistanceView_Dynamic.smubin  - tests/data/yaz0/Demo109_1.sbreviewtex  - tests/data/yaz0/A-1.00.sstats  - tests/data/yaz0/Rollpict001.sbstftex  - tests/data/A-1.00_Clustering.blwp  - (tests/_setup.sh)  - tests/stat.bats  - tests/bfres.bats  - tests/yaz0.bats  - tests/sarc.bats  - tests/byml.bats  - tests/bfsar.bats  - tests/blwp.bats  - tests/bars.bats ~ fileutil -v file-5.37 magic file from /usr/local/Cellar/libmagic/5.37/share/misc/magic
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	file.2019-07-04.19-11.gz (3,550 bytes) 2019-07-04 20:20 https://bugs.astron.com/file_download.php?file_id=59&type=bug file.tests.2019-07-04.19-19.gz (2,485 bytes) 2019-07-04 20:20 https://bugs.astron.com/file_download.php?file_id=60&type=bug file.2019-07-07.10-42.gz (2,777 bytes) 2019-07-07 17:32 https://bugs.astron.com/file_download.php?file_id=61&type=bug file.2019-07-07.13-32.gz (27,358 bytes) 2019-07-07 17:32 https://bugs.astron.com/file_download.php?file_id=62&type=bug file.2019-22-08.22-33.gz (1,748 bytes) 2019-08-23 02:35 https://bugs.astron.com/file_download.php?file_id=74&type=bug

Notes
(0003258) Pysis    2019-07-07 17:32	From the file headers: grep -oPiz '\n\n#-+\n([^\n]+?)\n#[^\n]+?\n' \       console \       | grep -oPiz '\n\n#-+\n([^\n]+?)\n' \       | grep -oPiz '\w.+?\n' \       | sed 's|\x0||g' \       > reference/file_current_console_magics.txt Only from the section headers: grep -oPiz '\n\n#-+\n([^\n]+?)\n#\n' \         console \         | grep -oPiz '\w.+?\n' \         | sed 's|\x0||g' \         > reference/file_current_console_magic_sections.txt
(0003262) christos    2019-07-21 09:35	Some of these are too weak (too few bytes of magic and the magic is text) so they would be produce spurious matches to text files. We should add these commented out. These days the minimum magic is around 32 bits. Can you restructure (where possible) the magic to look like: 0x0 string SARC >0x6 beshort 0xFEFF SARC archive file, BOM Big Endian, >> use nintendo_sark >0x6 beshort 0xFFFE SARC archive file, BOM Little Endian, >>0 use nintendo_sark 0 name nintendo_sark !:ext sarc >0x4 beshort x Header length %xh, >0x8 belong x File size %d bytes, >0x0C belong x Data offset %xh, >0x10 beshort x Version Number %d This way you need SARK and a valid BOM for a match. What do you think?
(0003286) Pysis    2019-08-23 02:18	Sorry for the delay. I saw that note, but I believe those 4 ASCII letters do technically suffice. I see what you mean as an alternative, and it seems ok, but the way I have it just seems cleaner and done.
(0003304) christos    2019-09-12 16:02	The advantage of my approach is that it makes the effective magic 8 bytes... I.e. it requires SARC\xfe\xff or SARC\xff\xfe before a match instead of just SARK.
(0003312) Pysis    2019-10-05 22:50	But they're fine as is and if people confuse an ASCII and proprietary binary file using this then they have a bigger problem.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
127	[file] General	minor	always	2019-12-21 08:31	2019-12-24 17:41
Reporter:	pierre	Platform:	Linux from scratch
Assigned To:	christos	OS:	GNU/Linux
Priority:	normal	OS Version:
Status:	feedback	Product Version:	5.38
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Problems building when only a static libbz2 is installed
Description:	There are two issues actually, the second one I think can be easily fixed: 1. When building file in chapter 5 of LFS (http://www.linuxfromscratch.org/lfs/view/development/), there is only libbz2.a available. This leads to an error when linking libmagic, since it tries to link a shared library with a static one. This can be worked around in two ways (either --disable-bzlib, or --disable-shared --enable-static), but maybe there could be a check somewhere to rpevent this from happening. 2. Now, when building in chapter 6, the libbz2 library is not found by configure, but the bzip.h header is found. This leads correctly to /* #undef BZLIBSUPPORT */ and #define HAVE_BZLIB_H 1 in config.h. But then, src/compress.c has: #if defined(HAVE_BZLIB_H) || defined(BZLIBSUPPORT) #define BUILTIN_BZLIB #include <bzlib.h> #endif then #ifdef BUILTIN_BZLIB private int uncompressbzlib(const unsigned char *, unsigned char **, size_t,     size_t *); #endif so that BZ2_bzDecompressInit is called, and leads to undefined symbols...
Tags:	compression
Steps To Reproduce:	Remove libbz2.so - > first issue Remove libbz2.* and keep /usr/include/bzip.h -> second issue
Additional Information:	I guess the second issue is because the stanza in compress.c should be: #if defined(HAVE_BZLIB_H) && defined(BZLIBSUPPORT) #define BUILTIN_BZLIB #include <bzlib.h> #endif (change || to &&, as is done with zlib). Note that I think there is the same issue with xz, but I have not tested.
Attached Files:

Notes
(0003340) christos    2019-12-24 17:41	I fixed the ifdef's but I don't see an easy way to check for shared libraries in autoconf: https://www.gnu.org/software/gnulib/manual/html_node/Searching-for-Libraries.html

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
125	[file] General	crash	always	2019-12-11 01:15	2019-12-13 16:57
Reporter:	ahupp	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	feedback	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Crash with MAGIC_COMPRESS and magic_buffer
Description:	(I already reported this, but it does not appear in my list of submitted bugs here so re-submitting). With libmagic 5.25, running magic_buffer on the contents of a Microsoft Word .docx file and MAGIC_COMPRESS enabled produced a crash. For some reason I'm not able to capture a stack in gdb. This does not reproduce in 5.30, nor with magic_file. I'm reporting despite the fact that it's apparently fixed in case this is a security issue; 5.25 is in Ubuntu Xenial and that's supported for 5 more years. Original report here: https://github.com/ahupp/python-magic/issues/200
Tags:
Steps To Reproduce:	adam@gaba:~/file-5.25/src/.libs$ LD_LIBRARY_PATH=. PYTHONPATH=../../python python Python 2.7.13 (default, Sep 26 2018, 18:42:22) [GCC 6.3.0 20170516] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import magic >>> m=magic.open(magic.MAGIC_COMPRESS) >>> m.load('/home/adam/file-5.25/magic/magic.mgc') 0 >>> m.buffer(open('/home/adam/test.docx').read()) adam@gaba:~/file-5.25/src/.libs$
Additional Information:	I've attached a sample empty word doc to aid reproducing the issue.
Attached Files:	test.docx (6,087 bytes) 2019-12-11 01:15 https://bugs.astron.com/file_download.php?file_id=93&type=bug

Notes
(0003339) christos    2019-12-13 16:57	The responsibility for fixing this should be with the xenial folks. They chose the version of file to support and the period of time to support it. They can always upgrade to a newer one or track or fix the bug themselves.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
88	[tcsh] General	minor	always	2019-06-27 01:14	2019-12-05 01:17
Reporter:	sharifib	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	6.21.00
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	6.22.03
		Target Version:
Summary:	:q does not preserve empty strings
Description:	The :q modifier appears to skip empty strings. This makes it very difficult to pass verbatim arguments to another program.
Tags:
Steps To Reproduce:	Minimal example: > echo $tcsh 6.21.00 > set arr= ( '1st arg' '' '3rd arg' ) > echo ${#arr} 3 > tcsh -c 'echo ${#argv}' $arr:q 2 > tcsh -c 'echo ${#argv}' '1st arg' '' '3rd arg' 3 Expected result: 3 3 3
Additional Information:	This is not new behavior, but complicates writing scripts that want to maintain and pass a variable number of arguments to other programs, some of which could possibly be empty. For example, something like the env command which may consume some initial arguments but does an exec with the remaining verbatim arguments. In tcsh, attempting to do the same with exec $argv[2-]:q apparently doesn't preserve any of the empty arguments.
Attached Files:

Notes
(0003256) sharifib    2019-06-27 01:18	Another example: > set arr= ( '1st arg' '' '3rd arg' ) > set arr2= ( $arr:q ) > echo ${#arr} 3 > echo ${#arr2} 2 Expected result: 3 3
(0003276) christos    2019-08-01 16:05	Fixed, thanks!
(0003337) christos    2019-11-30 14:52	I had to revert the change because it causes NUL characters inside expanded strings...
(0003338) christos    2019-12-05 01:17	Committed a new Q modifier so $args:gQ should DTRT.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
121	[file] General	trivial	always	2019-11-12 18:10	2019-11-19 05:41
Reporter:	roramirez	Platform:
Assigned To:	christos	OS:
Priority:	low	OS Version:
Status:	resolved	Product Version:	5.37
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.38
		Target Version:
Summary:	[PATCH] tab tests/test.c
Description:	Fix tab in test.c
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	00eb39616db1ca824f3e670a53dc1a7e8475b073.patch (854 bytes) 2019-11-12 18:10 https://bugs.astron.com/file_download.php?file_id=90&type=bug

Notes
(0003336) christos    2019-11-19 05:41	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
122	[file] General	minor	always	2019-11-12 18:15	2019-11-19 05:39
Reporter:	roramirez	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.38
		Target Version:
Summary:	[PATCH] Add test for ARM
Description:	Add test for Adaptive Multi-Rate Codec (GSM telephony) format
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	63915ccf157b586a39023de666f0f891e5b3b4ac.patch (19,660 bytes) 2019-11-12 18:15 https://bugs.astron.com/file_download.php?file_id=91&type=bug

Notes
(0003335) christos    2019-11-19 05:39	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
124	[file] General	minor	always	2019-11-14 17:13	2019-11-19 05:30
Reporter:	Essem	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.37
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.38
		Target Version:
Summary:	S3M files detected as mimetype application/octet-stream
Description:	Hello, I was wondering whether file could report the mime type for S3M files, especially considering that other audio module formats are correctly reported. However, when I tried to check the mime type for these files, they were reported as a generic octet stream. This confused me especially since the source code references these files alongside their mime types in /magic/Magdir/audio at around line 128. Why is file/libmagic not reporting the correct mime type if it's defined in the code? An example file showing this behavior has been attached.
Tags:	magic
Steps To Reproduce:	$ file <filename>.s3m <filename>.s3m: ScreamTracker III Module sound data Title: "<title>" $ file --mime-type <filename>.s3m <filename>.s3m: application/octet-stream
Additional Information:
Attached Files:	CLICK.S3M (295,008 bytes) 2019-11-14 17:13 https://bugs.astron.com/file_download.php?file_id=92&type=bug

Notes
(0003334) christos    2019-11-19 05:30	Added.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
120	[file] General	minor	always	2019-11-12 18:08	2019-11-19 05:25
Reporter:	roramirez	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.37
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.38
		Target Version:
Summary:	[PATCH] tests/test ignore
Description:	Add into .gitignore the file tests/test
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	8d57fd78109f1169aebff8334b44867f64c3fd39.patch (546 bytes) 2019-11-12 18:08 https://bugs.astron.com/file_download.php?file_id=89&type=bug

Notes
(0003333) christos    2019-11-19 05:25	Added.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
123	[file] General	minor	have not tried	2019-11-13 15:21	2019-11-19 05:22
Reporter:	progval	Platform:
Assigned To:	christos	OS:
Priority:	low	OS Version:
Status:	resolved	Product Version:	5.35
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Character 0x1C prevents a file from being detected as text
Description:	Hello, Inserting 0x1C in a text file (ASCII or UTF-8) makes `file`/libmagic detect it as "data" instead of "ASCII text" or "UTF-8 Unicode text". I'm not sure this is a bug as this character is non-printable, feel free to close this ticket if it isn't.
Tags:
Steps To Reproduce:	$ echo "abcde \x1c fghij" > test.txt $ file test.txt test.txt: data
Additional Information:
Attached Files:

Notes
(0003332) christos    2019-11-19 05:22	Will not fix. 0x1c is "File Separator" and typically does not belong in text files (it is a control character).

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
119	[file] General	minor	always	2019-11-03 06:22	2019-11-09 00:36
Reporter:	atrosinenko	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.37
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.38
		Target Version:
Summary:	UBSan: funcs.c:576:9: runtime error: null pointer passed as argument 1, which is declared to never be null
Description:	Memset is called with the `NULL` pointer.
Tags:
Steps To Reproduce:	1. Clone the fresh repo, tested on commit 069daf5c 2. autoreconf -i 3. ./configure CC=clang CFLAGS=-fsanitize=undefined --disable-libseccomp 4. make 5. Execute ``` $ ./src/file -m magic/magic.mgc /tmp/file-memset-null.bin funcs.c:576:9: runtime error: null pointer passed as argument 1, which is declared to never be null /usr/include/string.h:60:62: note: nonnull attribute specified here /tmp/file-memset-null.bin: JPEG image data, baseline, precision 0, 0x0, components 0 ```
Additional Information:
Attached Files:	file-memset-null.bin (160 bytes) 2019-11-03 06:22 https://bugs.astron.com/file_download.php?file_id=88&type=bug

Notes
(0003331) christos    2019-11-09 00:36	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
118	[file] General	minor	always	2019-11-03 06:03	2019-11-09 00:31
Reporter:	atrosinenko	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.37
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.38
		Target Version:
Summary:	UBSan: readelf.c:1350:19: runtime error: signed integer overflow: 4281348144 + 9223372033368272944 cannot be represented in type
Description:	The attached fuzzed file triggers signed integer overflow in calculation of `pread` arguments.
Tags:
Steps To Reproduce:	1. Clone the fresh repository, tested on commit 069daf5c 2. autoreconf -i 3. ./configure CC=gcc CFLAGS=-fsanitize=undefined --disable-libseccomp 4. make 5. Execute ``` $ ./src/file -m magic/magic.mgc /tmp/file-int-overflow.bin readelf.c:1350:19: runtime error: signed integer overflow: 4281348144 + 9223372033368272944 cannot be represented in type 'long int' /tmp/file-int-overflow.bin: ERROR: error reading (Invalid argument) ```
Additional Information:
Attached Files:	file-int-overflow.bin (285 bytes) 2019-11-03 06:03 https://bugs.astron.com/file_download.php?file_id=87&type=bug

Notes
(0003330) christos    2019-11-09 00:31	Thanks, now I check the offset against the file size.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
111	[file] General	minor	always	2019-10-06 10:20	2019-11-02 18:44
Reporter:	doronbehar	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	acknowledged	Product Version:	5.37
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Support for brotli compressed file detection
Description:	https://en.wikipedia.org/wiki/Brotli, is a new compression algorithm implemented by google. It is already supported by most browsers. it seems it's mime type should be `application/x-brotli`. Currently, `file` detects it as `application/octet-stream`. It seems that Google's implementation doesn't include the magic bytes needed for libmagic to detect it - there's an open issue about it: https://github.com/google/brotli/issues/727 So I thought an issue should be opened here as well.
Tags:	magic
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003329) christos    2019-11-02 18:44	Yes, this needs to be changed upstream.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
109	[file] General	minor	always	2019-09-27 12:10	2019-11-02 18:42
Reporter:	bcb	Platform:	Linux
Assigned To:	christos	OS:	Arch Linux
Priority:	normal	OS Version:
Status:	feedback	Product Version:	5.37
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	reStructuredText with embedded code detected as Python script
Description:	We're documenting our Python project with reStructuredText files. These contain various snippets of Python code which serve as examples. I've attached a simple document showing this. When run on this document, file picks up on the embedded code and detects it as a Python script: $ file -v file-5.37 magic file from /usr/share/file/misc/magic $ file document.rst document.rst: Python script, ASCII text executable $ file -b --mime-type document.rst text/x-python The particular use-case where we ran into this was in a Git hook which runs a code formatting tool to reject any Python code which doesn't meet the project coding style. It was using file to only run the checker on Python files. For the time being we've changed this to a simple file extension test. Note that it doesn't happen on every document, just those with enough magic matches to get the strength high enough. On documents which don't meet the threshold it reports "ASCII text text/plain". Ideally, it would report this in all cases.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	document.rst (566 bytes) 2019-09-27 12:10 https://bugs.astron.com/file_download.php?file_id=84&type=bug

Notes
(0003328) christos    2019-11-02 18:42	Added some magic to recognize ReStructuredText but it is not easy as there is no pattern for it.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
117	[file] General	minor	always	2019-10-31 15:42	2019-11-02 18:18
Reporter:	jagdpanther	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	feedback	Product Version:	5.37
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	file --mime result for gzip changed in 5.37
Description:	In file-5.36 (and prior) "file --mime" for a <file>.tar.gz file returned "application/x-gzip". Now in file-5.37 the same files returns "application/gzip".
Tags:
Steps To Reproduce:	file --mime <gzip file>     (while using file-5.37)
Additional Information:	This is an issue for programmatic use of "file --mime" and expecting "application/x-gzip" for .gz files.
Attached Files:

Notes
(0003327) christos    2019-11-02 18:18	Yes, unfortunately file output changes periodically because standards evolve. In this case file follows the recommendation from https://tools.ietf.org/html/rfc6713, which was ratified in 2012

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
115	[file] General	minor	always	2019-10-28 17:21	2019-11-02 18:15
Reporter:	ikrivosheev	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.37
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	PDF file detect fix
Description:	A pdf file is defined as "text/c-x".
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	0001-Detect-pdf-fix.patch (1,218 bytes) 2019-10-28 17:21 https://bugs.astron.com/file_download.php?file_id=86&type=bug foxit-reader-9.0.1.1049.pdf (3,369 bytes) 2019-10-28 17:21 https://bugs.astron.com/file_download.php?file_id=85&type=bug

Notes
(0003322) christos    2019-10-30 03:02	My guess is that this is some hand-crafted pdf file that does not follow the standard. Instead of fixing the magic I suggest that you ask the author to change his file. Quiting from: https://en.wikipedia.org/wiki/PDF: A PDF file is a 7-bit ASCII file, except for certain elements that may have binary content. A PDF file starts with a header containing the magic number and the version of the format such as %PDF-1.7. The format is a subset of a COS ("Carousel" Object Structure) format.[15] A COS tree file consists primarily of objects, of which there are eight types:[16]
(0003324) ikrivosheev    2019-10-30 14:38	Ok, I think we can close issue.
(0003326) christos    2019-11-02 18:15	Won't fix. Problem with hand-crafted PDF file.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
116	[file] General	feature	always	2019-10-30 07:38	2019-11-02 18:14
Reporter:	fractale	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.38
		Target Version:
Summary:	support lepton file type
Description:	lepton file are detect like data or dBase IV DBT lepton is a compressed jpeg develop by dropbox https://github.com/dropbox/lepton
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003325) christos    2019-11-02 18:14	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
114	[file] General	minor	always	2019-10-21 13:53	2019-10-30 03:17
Reporter:	danyspin97	Platform:	Linux
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.37
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.38
		Target Version:
Summary:	zsh shellscript recognized as plain text when the shebang is "#!/usr/bin/env zsh"
Description:	zsh shellscrpt is incorrectly reported as plain text when --mime-type arg is passed and the shebang of the script is "#!/usr/bin/env zsh". Without --mime-type, it is reported as zsh script. Changing the shebang to "#!/usr/bin/zsh", makes file recognize the script. "#!/usr/bin/env bash" is used, the script is correctly recognized as shellscript.
Tags:
Steps To Reproduce:	echo "#!/usr/bin/env zsh" > myzshscript && chmod +x myzshscript && file --mime-type myzshscript
Additional Information:
Attached Files:

Notes
(0003323) christos    2019-10-30 03:17	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
59	[file] General	minor	always	2019-01-30 11:43	2019-10-29 01:18
Reporter:	magicus	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:	5.35
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Magic is missing for Java jmod and module image files
Description:	There is no magic formula for Java jmod and image files (as produced by jlink); these are artefacts generated by Java since JDK 9.
Tags:
Steps To Reproduce:	Actual results: $ file jdk/jmods/java.base.jmod jdk/jmods/java.base.jmod: Zip archive data $ file jdk/lib/modules jdk/lib/modules: data Expected results: $ file jdk/jmods/java.base.jmod jdk/jmods/java.base.jmod: Java jmod module, version 1.0 $ file jdk/lib/modules jdk/lib/modules: Java module image (little endian), version 1.0
Additional Information:	Provided patch has been tested on all three types (jmod, BE image and LE image), and a sanity check that it did not break zip detection.
Attached Files:	add-java-jmod-and-image.patch (1,190 bytes) 2019-01-30 11:43 https://bugs.astron.com/file_download.php?file_id=38&type=bug

Notes
(0003209) christos    2019-02-18 16:53	Thanks! JM magic is too short. I only added it for v1.0 so that it does not generate false positives.
(0003319) magicus    2019-10-23 11:35	I just noticed right now that my patch got stuck here, sorry for the long delay in my response. I'm not sure what you mean. By "JM magic", do you mean the jmod beshort 0x4a4d marker? I agree that a 32 bit marker had been preferable, but that's not the way the file format is designed. :-( The jmod header is followed by a zip entry. Is there a way to link this requirement to the zip definition? If so, the identification mechanism surely cannot be too generic. (I assume you worry about false positives.) I do not understand the syntax of the magic file good enough to figure out how to do that, if it's possible. I can see only four possible solutions: 1) specify that a zip header must follow (if this possible) 2) copy/reimplement the definition of the zip header with a slight offset into the jmod definition 3) accept the entry anyway, since we have nothing else to go on 4) omit that part of the patch and never be able to support jmod files
(0003320) magicus    2019-10-23 11:43	Ah, now I understand. 0x4a4d of course spells "JM". And what you are saying is that if I hard-code the match to jmod version 1.0, I'd get 0x4a4d0100, and that would be an acceptable magic marker?
(0003321) christos    2019-10-29 01:18	Yes, that would even be better (to make it look further for a zip header... I've already added the 0100, but we can make it better if we just match on the JM then the zip header and print the version dynamically...

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
113	[tcsh] General	major	always	2019-10-11 22:04	2019-10-19 12:54
Reporter:	sobomax	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	6.22.00
		Target Version:
Summary:	Error handling is seriously broken in kill built-in when started in non-interactive mode and with SIGINT ignored
Description:	We were investigating an issue with one of our Jenkins script hanging indefinitely with 100% CPU usage occasionally. It appears that very simple command such as tcsh -c "kill TERM XYZ" just hangs forever in an infinite loop when the following 3 conditions are met: 1. tcsh is started with standard output being anything but terminal (file, dev null, pipe); 2. Parent process that invoked tcsh sets SIGINT to SIG_IGN, in our case, we are starting it using su(1) which does it apparently; 3. kill(2) fails (e.g. ENOENT, etc). The issue seems to be [Free]BSD specific, as we cannot reproduce it on Linux using the very same version of the software. The tcsh invokes kill(2) over and over again. 14:46:59.309 95884: No such process 14:46:59.309 95884: No such process 14:46:59.309 95884: No such process 14:46:59.309 95884: No such process 14:46:59.309 95884: No such process [...ad infinitum...]
Tags:
Steps To Reproduce:	#include <assert.h> #include <fcntl.h> #include <signal.h> #include <unistd.h> int main(void) {   int devnull;   assert(signal(SIGINT, SIG_IGN) != SIG_ERR);   devnull = open("/dev/null", O_WRONLY);   assert(devnull >= 0);   assert(dup2(devnull, STDOUT_FILENO) >= 0);   assert(close(devnull) == 0);   execl("/bin/tcsh", "/bin/tcsh", "-c", "kill -TERM 99999", NULL);   return (255); }
Additional Information:	Version 6.20.00.
Attached Files:

Notes
(0003315) sobomax    2019-10-11 22:17	This is how it looks while it hangs: 99089 - R 53:05.77 _su -m -c kill -TERM 95884 (csh) Some of the ktrace logs of the actual issue (not our simulated test case):  99089 csh CALL ioctl(0x6,TIOCGETA,0x7fffffffc1d8)  99089 csh RET ioctl -1 errno 25 Inappropriate ioctl for device  99089 csh CALL sigprocmask(SIG_SETMASK,0x687fd0,0)  99089 csh RET sigprocmask 0  99089 csh CALL close(0x6)  99089 csh RET close 0  99089 csh CALL openat(AT_FDCWD,0x8014407f0,0<O_RDONLY>)  99089 csh NAMI "/root/.history"  99089 csh RET openat -1 errno 13 Permission denied  99089 csh CALL sigprocmask(SIG_BLOCK,0,0x687fd0)  99089 csh RET sigprocmask 0  99089 csh CALL setitimer(0,0x7fffffffe400,0x7fffffffe3e0)  99089 csh STRU itimerval { .interval = {0, 0}, .value = {0, 0} }  99089 csh STRU itimerval { .interval = {0, 0}, .value = {0, 0} }  99089 csh RET setitimer 0  99089 csh CALL close(0)  99089 csh RET close -1 errno 9 Bad file descriptor  99089 csh CALL dup(0x13)  99089 csh RET dup 0  99089 csh CALL fcntl(0,F_SETFD,0)  99089 csh RET fcntl 0  99089 csh CALL close(0x1)  99089 csh RET close -1 errno 9 Bad file descriptor  99089 csh CALL dup(0x11)  99089 csh RET dup 1  99089 csh CALL fcntl(0x1,F_SETFD,0)  99089 csh RET fcntl 0  99089 csh CALL close(0x2)  99089 csh RET close -1 errno 9 Bad file descriptor  99089 csh CALL dup(0x12)  99089 csh RET dup 2  99089 csh CALL fcntl(0x2,F_SETFD,0)  99089 csh RET fcntl 0  99089 csh CALL sigprocmask(SIG_BLOCK,0,0x687fd0)  99089 csh RET sigprocmask 0  99089 csh CALL kill(0x1768c,SIGTERM)  99089 csh RET kill -1 errno 3 No such process  99089 csh CALL stat(0x7fffffffd9c0,0x7fffffffd948)  99089 csh NAMI "/usr/share/nls/C/libc.cat"  99089 csh RET stat -1 errno 2 No such file or directory  99089 csh CALL stat(0x7fffffffd9c0,0x7fffffffd948)  99089 csh NAMI "/usr/share/nls/libc/C"  99089 csh RET stat -1 errno 2 No such file or directory  99089 csh CALL stat(0x7fffffffd9c0,0x7fffffffd948)  99089 csh NAMI "/usr/local/share/nls/C/libc.cat"  99089 csh RET stat -1 errno 2 No such file or directory  99089 csh CALL stat(0x7fffffffd9c0,0x7fffffffd948)  99089 csh NAMI "/usr/local/share/nls/libc/C"  99089 csh RET stat -1 errno 2 No such file or directory  99089 csh CALL write(0x1,0x6aa960,0x17)  99089 csh GIO fd 1 wrote 23 bytes        "95884: No such process        "  99089 csh RET write 23/0x17  99089 csh CALL lseek(0x10,0,SEEK_END)  99089 csh RET lseek -1 errno 29 Illegal seek  99089 csh CALL sigprocmask(SIG_SETMASK,0x687fd0,0)  99089 csh RET sigprocmask 0  99089 csh CALL sigprocmask(SIG_BLOCK,0,0x687fd0)  99089 csh RET sigprocmask 0  99089 csh CALL sigprocmask(SIG_SETMASK,0x687fd0,0)  99089 csh RET sigprocmask 0  99089 csh CALL sigprocmask(SIG_BLOCK,0,0x687fd0)  99089 csh RET sigprocmask 0  99089 csh CALL setitimer(0,0x7fffffffe400,0x7fffffffe3e0)  99089 csh STRU itimerval { .interval = {0, 0}, .value = {0, 0} }  99089 csh STRU itimerval { .interval = {0, 0}, .value = {0, 0} }  99089 csh RET setitimer 0  99089 csh CALL close(0)  99089 csh RET close 0  99089 csh CALL dup(0x13)  99089 csh RET dup 0  99089 csh CALL fcntl(0,F_SETFD,0)  99089 csh RET fcntl 0  99089 csh CALL close(0x1)  99089 csh RET close 0  99089 csh CALL dup(0x11)  99089 csh RET dup 1  99089 csh CALL fcntl(0x1,F_SETFD,0)  99089 csh RET fcntl 0  99089 csh CALL close(0x2)  99089 csh RET close 0  99089 csh CALL dup(0x12)  99089 csh RET dup 2  99089 csh CALL fcntl(0x2,F_SETFD,0)  99089 csh RET fcntl 0  99089 csh CALL sigprocmask(SIG_BLOCK,0,0x687fd0)  99089 csh RET sigprocmask 0  99089 csh CALL kill(0x1768c,SIGTERM)  99089 csh RET kill -1 errno 3 No such process  99089 csh CALL write(0x1,0x6aa960,0x17)  99089 csh GIO fd 1 wrote 23 bytes        "95884: No such process        " [cycle repeats after that]
(0003316) christos    2019-10-19 12:54	FIxed on HEAD, please re-open if you have issues.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
112	[file] General	minor	always	2019-10-06 13:43	2019-10-08 20:25
Reporter:	connesc	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.37
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.38
		Target Version:
Summary:	Incorrect output with -iz on gzip file
Description:	Starting with v5.37, combining -i and -z leads to incorrect results for gzip files. Running it on a gzipped text file produces: text/plain; charset=us-ascii compressed-encoding=application/octet-stream; charset=binary Versions bellow v5.37 produce what I would expect: text/plain; charset=us-ascii compressed-encoding=application/x-gzip; charset=binary
Tags:
Steps To Reproduce:	# Create a simple test file gzip <<< 'Hello World!' > hello.txt.gz # Call file 5.37 with -i and -z file -biz hello.txt.gz
Additional Information:	I guess that gzip is properly detected since it is reported without -i. Only the MIME output seems to be broken. Also, I get a correct output when using the v5.37 binary with the v5.36 magic file.
Attached Files:

Notes
(0003314) christos    2019-10-08 20:25	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
110	[file] General	minor	have not tried	2019-10-05 15:06	2019-10-08 14:26
Reporter:	rickrich	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	feedback	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	3D STL files needs help
Description:	$ file 0.stl 0.stl: data $ xod 0.stl | head -9 Dump: 0.stl Offset: 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00000000: 53 54 4c 42 20 41 54 46 20 38 2e 32 2e 30 2e 31 | STLB ATF 8.2.0.1 | 00000010: 30 32 39 20 43 4f 4c 4f 52 3d a0 a0 a0 ff 20 20 | 029 COLOR=.... | 00000020: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 | | *
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003311) rickrich    2019-10-05 15:08	https://en.wikipedia.org/wiki/STL_(file_format)
(0003313) christos    2019-10-08 14:26	https://all3dp.com/what-is-stl-file-format-extension-3d-printing/ https://en.wikipedia.org/wiki/STL_(file_format) There seems to be no magic number for the binary format or any kind of structure except that it perhaps contains COLOR= Am I missing something?

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
107	[file] General	feature	always	2019-09-26 01:39	2019-09-30 15:51
Reporter:	lucas.hartmann	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.36
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.38
		Target Version:
Summary:	Add report for squashfs compression algorithm
Description:	Feature request: Report compression algorithm for squashfs files. Compression is included in the squashfs superblock, uint16_t at offset 20 from the start of the file. Values are: 0 - uncompressed (unsure) 1 - zlib compressed 2 - lzma compressed 3 - lzo compressed 4 - xz compressed 5 - lz4 compressed 6 - zstd compressed Source: *_COMPRESSION macros, and struct squashfs_super_block at https://sourceforge.net/p/squashfs/code/ci/master/tree/squashfs-tools/squashfs_fs.h#l295
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	squashfs_compression.patch (1,040 bytes) 2019-09-26 15:09 https://bugs.astron.com/file_download.php?file_id=83&type=bug

Notes
(0003308) lucas.hartmann    2019-09-26 15:09	This may do it.
(0003310) christos    2019-09-30 15:51	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
108	[file] General	trivial	always	2019-09-26 14:05	2019-09-30 15:45
Reporter:	izhidkov	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.37
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.38
		Target Version:
Summary:	Incorrect mime type for sgml/svg
Description:	SVG spec v1.1 and v1.2 both describe SVG mime type only as 'image/svg+xml', there is no option without '+xml' link to spec v1.1 https://www.w3.org/TR/SVG11/mimereg.html link to spec v1.2 https://www.w3.org/TR/SVGTiny12/mimereg.html magic/Magdir/sgml:13 describe it as 'image/svg' which is incorrect according to spec
Tags:	magic
Steps To Reproduce:	Try to detect mime type of text file with content(also attached as file): <svg xmlns="http://www.w3.org/2000/svg" enable-background="new 0 0 30 30" version="1.1" viewBox="0 0 30 30" style="zoom: 1;" width="240(null)" height="240(null)"><rect x="-1.997164px" y="-6.79887px" width="800px" fill="#303860" height="800px"></rect><g fill="#fff"><path d="M25.5,4.4 c1.6,-0.6 2.9,-0.1 3,0 c-0.1,0 -1.3,0.2 -2.3,1.3 s-1.9,2.7 -2.4,3.4 c-1.4,2 -2.7,2.8 -4.3,3.2 c-2,0.5 -3.2,-0.6 -3.3,-0.7 c0.1,0 1.3,0.3 2.4,-0.5 c1.1,-0.7 2.3,-2.3 3.1,-3.4 c1.2,-1.6 2.4,-2.7 3.8,-3.3 m-22.4,2.8 c-1.4,-1.1 -1.6,-2.6 -1.6,-2.6 s0.8,1.1 2.3,1.3 c1.5,0.3 3.3,0.3 4.2,0.4 c2.5,0.2 3.8,1 4.9,2.2 c1.4,1.5 1,3.1 1.1,3.2 c0,-0.1 -0.4,-1.2 -1.6,-1.8 s-3.1,-0.8 -4.5,-1 c-2.1,-0.3 -3.7,-0.8 -4.8,-1.7 m13.6,18 c-0.2,1.7 -1.4,2.5 -1.4,2.6 c0,-0.1 0.5,-1.2 0,-2.6 s-1.4,-3 -1.8,-3.8 c-1.1,-2.2 -1,-3.7 -0.6,-5.3 c0.6,-2 2.2,-2.4 2.2,-2.5 c-0.1,0.1 -0.9,1 -0.8,2.3 c0,1.3 0.8,3.1 1.4,4.4 c0.8,1.8 1.2,3.5 1,4.9 z "></path><path d="m17.2 13c0.6 0.3 1.7 0.4 2.4 0.6 1.1 0.1 2 0.4 2.6 0.9 0.7 0.6 0.8 1.4 0.8 1.4s-0.4-0.6-1.2-0.7c-0.8-0.2-1.8-0.2-2.2-0.2-1.3-0.1-2-0.5-2.6-1.2-0.7-0.8-0.6-1.6-0.6-1.7 0 0 0.2 0.6 0.8 0.9"></path><path d="m15 11c0.1 0 0.8-0.4 1-1.2 0.3-0.8 0.2-2.1 0.1-3-0.1-1.3 0-2.4 0.5-3.3 0.5-1 1.5-1.3 1.5-1.3s-0.6 0.6-0.6 1.6 0.2 2.2 0.2 2.7c0.2 1.6-0.2 2.5-0.8 3.4-0.8 1.1-1.8 1.1-1.9 1.1"></path><path d="m14.7 10c0-0.7-0.4-1.7-0.7-2.4-0.4-1-0.7-1.9-0.5-2.7 0.1-0.9 0.8-1.4 0.8-1.4s-0.3 0.6 0 1.4c0.2 0.8 0.8 1.6 0.9 2.1 0.6 1.2 0.5 2 0.3 2.9-0.3 1-1.1 1.3-1.2 1.4 0-0.1 0.4-0.5 0.4-1.3"></path><path d="m14 13c-0.1 0-0.7-0.4-1.6-0.3-0.9 0.2-1.9 0.9-2.7 1.4-1.1 0.7-2.1 1.2-3.1 1.2-1.2 0-1.9-0.7-1.8-0.6 0 0 0.8 0.2 1.7-0.3s1.8-1.3 2.3-1.6c1.3-0.9 2.3-1.1 3.4-1 1.3 0.2 1.7 1.1 1.8 1.2"></path><path d="m13.3 13.7c-0.6 0.4-1.2 1.2-1.7 1.8-0.7 0.9-1.3 1.5-2.1 1.8-0.9 0.3-1.6 0-1.6 0s0.7-0.1 1.2-0.7 1-1.5 1.3-1.8c0.8-1.1 1.5-1.5 2.3-1.7 1.1-0.2 1.7 0.3 1.8 0.4 0.1 0-0.6-0.2-1.2 0.2"></path><path d="m16.2 12.9c0 0.1 0 0.9 0.6 1.5 0.6 0.7 1.7 1.2 2.6 1.6 1.2 0.6 2.1 1.2 2.6 2.1 0.6 1 0.4 1.9 0.4 1.9s-0.2-0.8-1.1-1.3c-0.8-0.5-2-0.9-2.5-1.2-1.5-0.7-2.1-1.5-2.5-2.4-0.7-1.3-0.1-2.2-0.1-2.2"></path><path d="m15.7 11.2c0.1 0 1-0.2 1.7-1 0.7-0.9 1.1-2.4 1.4-3.5 0.5-1.6 1.1-2.8 2-3.6 1.1-0.9 2.3-0.8 2.2-0.9 0 0-0.9 0.5-1.3 1.6-0.5 1.2-0.7 2.7-0.9 3.3-0.5 1.9-1.3 2.9-2.4 3.6-1.4 1-2.6 0.5-2.7 0.5"></path><path d="m13.8 12.3c-0.1-0.1-0.7-0.8-1.7-0.9-1.1-0.2-2.6 0.2-3.7 0.5-1.6 0.4-3 0.5-4.1 0.1-1.3-0.4-1.9-1.5-1.9-1.5s0.9 0.6 2.1 0.3c1.2-0.2 2.6-0.7 3.3-0.9 1.9-0.5 3.1-0.3 4.3 0.3 1.5 0.7 1.7 2 1.7 2.1"></path><path d="m15.7 13.4c0 0.1-0.4 1 0 2s1.5 2.1 2.3 3c1.1 1.2 1.9 2.3 2.1 3.5 0.3 1.3-0.3 2.3-0.4 2.4 0-0.1 0-1.1-0.8-2-0.8-1-1.9-1.9-2.4-2.4-1.4-1.4-1.8-2.6-1.9-3.9 0-1.7 1.1-2.5 1.1-2.6"></path></g></svg>
Additional Information:	Patch (also attached as file): --- a/file/magic/Magdir/sgml +++ b/file/magic/Magdir/sgml @@ -10,7 +10,7 @@  >>19 search/4096 \<gnc-v2 GnuCash file  !:mime application/x-gnucash  0 string \<svg SVG Scalable Vector Graphics image -!:mime image/svg +!:mime image/svg+xml  # Sitemap file  0 string/t \<?xml\ version=
Attached Files:	example.svg (2,727 bytes) 2019-09-26 14:05 https://bugs.astron.com/file_download.php?file_id=81&type=bug svg_magic.patch (288 bytes) 2019-09-26 14:05 https://bugs.astron.com/file_download.php?file_id=82&type=bug

Notes
(0003309) christos    2019-09-30 15:45	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
106	[file] General	trivial	N/A	2019-09-23 09:26	2019-09-23 13:04
Reporter:	chuckthedude	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.37
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.38
		Target Version:
Summary:	add support for ILDA files
Description:	Update magic to detect .lid ILDA files
Tags:
Steps To Reproduce:	chein@GeekLab-2 file % git diff origin/master master diff --git a/magic/Magdir/ilda b/magic/Magdir/ilda new file mode 100644 index 00000000..c5be6870 --- /dev/null +++ b/magic/Magdir/ilda @@ -0,0 +1,18 @@ + +#------------------------------------------------------------------------------ +# $File$ +# ilda: file(1) magic for ilda +# +# ILDA Image Data Transfer Format +# https://www.ilda.com/resources/StandardsDocs/ILDA_IDTF14_rev011.pdf +# +# Updated by Chuck Hein (laser@geekdude.com) +# + +0 string ILDA ILDA Image Data Transfer Format +>7 byte 0x00 3D Coordinates with Indexed Color +>7 byte 0x01 2D Coordinates with Indexed Color +>7 byte 0x02 Color Palette +>7 byte 0x04 3D Coordinates with True Color +>7 byte 0x05 2D Coordinates with True Color + diff --git a/magic/Makefile.am b/magic/Makefile.am index 6aeeb4ce..aee9d2bb 100644 --- a/magic/Makefile.am +++ b/magic/Makefile.am @@ -129,6 +129,7 @@ $(MAGIC_FRAGMENT_DIR)/ibm370 \  $(MAGIC_FRAGMENT_DIR)/ibm6000 \  $(MAGIC_FRAGMENT_DIR)/icc \  $(MAGIC_FRAGMENT_DIR)/iff \ +$(MAGIC_FRAGMENT_DIR)/ilda \  $(MAGIC_FRAGMENT_DIR)/images \  $(MAGIC_FRAGMENT_DIR)/inform \  $(MAGIC_FRAGMENT_DIR)/intel \
Additional Information:
Attached Files:	0001-Support-for-ILDA-files.patch (1,527 bytes) 2019-09-23 09:33 https://bugs.astron.com/file_download.php?file_id=79&type=bug formatt.ild (38,522 bytes) 2019-09-23 09:42 https://bugs.astron.com/file_download.php?file_id=80&type=bug

Notes
(0003305) chuckthedude    2019-09-23 09:33	patchfile
(0003306) chuckthedude    2019-09-23 09:42	Attached sample ILDA file for testing if desired or required. http://laserboy.org/formatt/formatt.ild From: http://laserboy.org/ilda_file_format.html A LOT MORE THAN YOU EVER WANTED TO KNOW ABOUT THE ILDA FILE FORMAT
(0003307) christos    2019-09-23 13:04	Added to images, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
105	[file] General	major	always	2019-09-11 06:12	2019-09-12 15:38
Reporter:	lighe	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	feedback	Product Version:	5.37
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Docx files exported by MacOS's Pages not recognized
Description:	1) Create a document in Pages 2) File > Export to > Word > Docx 3) file -i file.docx reports application/octet-stream; charset=binary instead of application/vnd.openxmlformats-officedocument.wordprocessingml.document; charset=binary Seems to be with any content.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	Incorrect.docx (383,370 bytes) 2019-09-11 06:12 https://bugs.astron.com/file_download.php?file_id=78&type=bug

Notes
(0003289) christos    2019-09-11 14:48	[10:46am] 191>./file macosx.docx macosx.docx: Microsoft Word 2007+ [10:46am] 192>./file -i macosx.docx macosx.docx: application/vnd.openxmlformats-officedocument.wordprocessingml.document; charset=binary [10:46am] 193>./file -v file-5.37 magic file from /usr/local/share/misc/magic What do you get?
(0003290) christos    2019-09-11 14:50	ah, there are some changes on HEAD which might have fixed the issue.
(0003299) lighe    2019-09-12 13:25	I am getting application/octet-stream; charset=binary
(0003300) lighe    2019-09-12 13:39	Sorry. file -v reportd file-5.30. So it looks like I confused myself thinking I'm on the latest version!
(0003301) christos    2019-09-12 15:38	please try with the latest version from github.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
95	[tcsh] General	minor	always	2019-08-01 14:59	2019-09-12 01:54
Reporter:	mnowak	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	6.21.00
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	'nice' test fails on OpenIndiana
Description:	68. commands.at:893: testing nice ... /export/home/newman/ws/oi-userland/components/shell/tcsh/tcsh-6.21.00/commands.at:896: tcsh -f -c 'nice set var=1; echo $?var' --- /dev/null 2019-08-01 16:49:34.000000000 +0000 +++ /export/home/newman/ws/oi-userland/components/shell/tcsh/build/amd64/testsuite.dir/at-groups/68/stderr 2019-08-01 16:49:36.642047795 +0000 @@ -0,0 +1 @@ +setpriority: Permission denied. 68. commands.at:893: 68. nice (commands.at:893): FAILED (commands.at:896)
Tags:
Steps To Reproduce:	Run tests as user like this: /usr/bin/env PATH=/usr/gnu/bin:/usr/bin:/usr/sbin:/usr/perl5/bin /usr/gnu/bin/make check Here GNU tools take precedence to illumos ones otherwise even more tests fail.
Additional Information:
Attached Files:	testsuite.log (91,561 bytes) 2019-08-01 14:59 https://bugs.astron.com/file_download.php?file_id=68&type=bug

Notes
(0003278) christos    2019-08-02 10:47	I can't reproduce this, but I fixed the tests so that the ones that failed because /usr/bin/false returns 255 instead of 0 are fixed.
(0003279) mnowak    2019-08-02 16:23	Right, now I see it pass too... Thanks.
(0003298) christos    2019-09-12 01:54	Submitter can't reproduce

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
100	[file] General	minor	always	2019-08-16 14:50	2019-09-11 22:55
Reporter:	SIGSTACKFAULT	Platform:	x86_64 (vbox)
Assigned To:	christos	OS:	Ubuntu
Priority:	low	OS Version:	19.04
Status:	resolved	Product Version:	5.35
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.38
		Target Version:
Summary:	device tree configuration (.dts) files listed as "C source"
Description:	Device tree configuration files, `.dts` are listed as "C source" files despite being, well, not C source code.
Tags:	magic
Steps To Reproduce:	For example, I'm going to use .dts files from the zephyr RTOS.     git clone https://github.com/zephyrproject-rtos/zephyr --depth 10     file zephyr/boards/arm/nrf52840_mdk/nrf52840_mdk.dts files in `zephyr/boards/*/*/*.dts` all do this. Some are listed as just "ASCII text". I'm not sure if that says anything about your C magic. One is marked as UTF-8 unicode but I think that's zephyr's fault. `--extension` doesn't help either.
Additional Information:
Attached Files:	reproduce.sh (98 bytes) 2019-08-16 14:50 https://bugs.astron.com/file_download.php?file_id=73&type=bug

Notes
(0003285) SIGSTACKFAULT    2019-08-16 15:04	The magic string you're looking for is "/dts-v1/", but it's not necessarily at the start; there may be comments before it.
(0003297) christos    2019-09-11 22:55	Added magic.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
98	[file] General	minor	always	2019-08-11 08:47	2019-09-11 16:59
Reporter:	johannes	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	feedback	Product Version:	5.37
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	LLVM Assembly Language files (*.ll) are reported as C source
Description:	Files containing the human-readable assembly language of the LLVM intermediate representation are mistakenly reported to be C source. Perhaps we can add some simple patterns to distuingish them. The mime type could be "text/x-llvm" or "text/x-llvm-ir". LLVM Language: https://llvm.org/docs/LangRef.html
Tags:
Steps To Reproduce:	$ cat > main.ll << EOF define i8 @main() {     ret i8 123 } EOF $ file main.ll main.ll: C source, ASCII text
Additional Information:	Here are some magic patterns I've been using which seem to work cat >> magic/Magdir/llvm <<EOF 0 search/8192 define LLVM Assembly Language text !:mime text/x-llvm >0 regex \^define 0 search/8192 declare LLVM Assembly Language text !:mime text/x-llvm >0 regex \^declare EOF
Attached Files:

Notes
(0003294) christos    2019-09-11 16:59	We need something stronger than that, otherwise many text files will match.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
102	[file] General	major	always	2019-08-30 02:59	2019-09-11 15:46
Reporter:	Sergei	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.37
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.38
		Target Version:
Summary:	Incorrect fix in "PR/518: Fall back to use setlocale() for the OS's that don't support"
Description:	Fix implemented by https://github.com/file/file/commit/b74175e236c34beeb930c95bb25300c92a205cd3 is incorrect: "setlocale" doesn't return previous locale like "uselocale" does. "setlocale" returns (man 3 setlocale): > RETURN VALUE > A successful call to setlocale() returns an opaque string that corresponds to the locale set. This string may be allocated in static storage. The > string returned is such that a subsequent call with that string and its associated category will restore that part of the process's locale. The > return value is NULL if the request cannot be honored. So that "rx->old_lc_ctype = setlocale(LC_CTYPE, "C");" and the likes is utterly wrong. I suggest using the original method from the commit "c397fb230f70cfa1dc8f3d387f4df8ebec6c1a63" to save locale. Patch attached. With best regards, Sergei.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	0001-Fix-locale-saving-when-using-setlocale.patch (2,179 bytes) 2019-08-30 02:59 https://bugs.astron.com/file_download.php?file_id=76&type=bug

Notes
(0003292) christos    2019-09-11 15:46	patch applied, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
103	[file] General	minor	always	2019-09-01 04:41	2019-09-11 15:20
Reporter:	stokito	Platform:
Assigned To:	christos	OS:
Priority:	high	OS Version:
Status:	resolved	Product Version:	5.37
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.38
		Target Version:
Summary:	ZStandard incorrect MIME type application/x-zstd
Description:	In the commit "PR/573: Nick Terrell: Add zstd support" https://github.com/file/file/commit/5b8826616cb699b69f7a1cc7b5c0cbac4b5bed9b was added a support for for ZStandard compressed files with "application/x-zstd" MIME type. But latter the official MIME type was assigned without the "x-" i.e. "application/zstd": https://www.iana.org/assignments/media-types/application/zstd https://tools.ietf.org/search/rfc8478 https://github.com/facebook/zstd/issues/767
Tags:	magic
Steps To Reproduce:	$ touch test.txt $ zstd test.txt test.txt :1300.00% ( 0 => 13 bytes, test.txt.zst) $ file -i test.txt.zst test.txt.zst: application/x-zstd; charset=binary
Additional Information:	All GUI archievers (Ark, File Roller, Engrampa) internally using the correct "application/zstd" MIME type
Attached Files:

Notes
(0003287) stokito    2019-09-04 19:46	BTW, only 0xFD2FB528 was standardized so we can remove all previous magic signatures. 0xFD2FB522 Zstandard compressed data (v0.2) 0xFD2FB523 Zstandard compressed data (v0.3) 0xFD2FB524 Zstandard compressed data (v0.4) 0xFD2FB525 Zstandard compressed data (v0.5) 0xFD2FB526 Zstandard compressed data (v0.6) 0xFD2FB527 Zstandard compressed data (v0.7)
(0003291) christos    2019-09-11 15:20	Fixed, thanks

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
97	[file] General	minor	have not tried	2019-08-06 14:41	2019-08-10 22:33
Reporter:	jidanni	Platform:	Debian
Assigned To:	christos	OS:	Linux
Priority:	normal	OS Version:
Status:	assigned	Product Version:	5.37
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	File misses the alpha channel sometimes
Description:	File misses the alpha channel in the second file! $ set slope.png zaokeng_slope.png $ identify -format '%[channels]\n' $@ srgba srgba $ file $@ slope.png: PNG image data, 640 x 220, 8-bit/color RGBA, non-interlaced zaokeng_slope.png: PNG image data, 700 x 400, 8-bit/color RGB, non-interlaced
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	zaokeng_slope.png (16,283 bytes) 2019-08-06 14:41 https://bugs.astron.com/file_download.php?file_id=70&type=bug slope.png (17,410 bytes) 2019-08-06 14:41 https://bugs.astron.com/file_download.php?file_id=71&type=bug

Notes
(0003283) christos    2019-08-10 13:27    (Last edited: 2019-08-10 13:28)	Well, "identify" is right and wrong. The second file is not rgba, it is rgb with extra transparency information in a "tRNS" chunk. Effectively this means that both files contain alpha info, but they are encoded differently. file(1) only looks at the IHDR section and does not do further processing to see if there are any other chunks. While we can make file(1) smarter about png files by parsing more of the png-file and all the additional chunks, and print additional information about it, it hardly seems worth-while. For reference: https://en.wikipedia.org/wiki/Portable_Network_Graphics
(0003284) jidanni    2019-08-10 22:33	(I was trying to scan for all files that would trigger https://bugs.chromium.org/p/chromium/issues/detail?id=991197 .) (OK, as you understand the issue perhaps you should file an Imagemagick bug.)

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
96	[file] General	feature	always	2019-08-02 20:34	2019-08-05 13:10
Reporter:	koala_man	Platform:
Assigned To:	christos	OS:
Priority:	low	OS Version:
Status:	resolved	Product Version:	5.37
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.38
		Target Version:
Summary:	Add support for Hermes compiled JavaScript bytecode
Description:	Hi! I am one of the developers of Hermes, a new JavaScript engine for mobile that pre-compiles JavaScript into bytecode. For your consideration, here is magic that can recognize our bytecode files (64bit magic + 32bit integer version, little-endian):     0 lequad 0x1F1903C103BC1FC6 Hermes compiled JavaScript bytecode,     >8 lelong x version %d I think there is a case for upstreaming this because: 1. the use of a 64bit magic number minimizes the risk of false positives, 2. it's convenient for mobile JS to be able to determine a file's bytecode version to check compatibility, and 3. there are already hundreds of millions of mobile devices carrying files in this format. Please let me know what you think.
Tags:	magic
Steps To Reproduce:	I have attached `hello.hbc`, a simple `print("Hello World");` compiled into Hermes bytecode using `hermes -O -emit-binary -out hello.hbc hello.js` Without the suggested magic, file's guess is `data`. With the magic, it says:     hello.hbc: Hermes compiled JavaScript bytecode, version 60
Additional Information:	Hermes is developed by Facebook and was open sourced in July 2019: https://hermesengine.dev/ The bytecode header and magic numbers can be found in: https://github.com/facebook/hermes/blob/a09052e901f4b8dc925e6d4bd0cc47171b90db5e/include/hermes/BCGen/HBC/BytecodeFileFormat.h#L24
Attached Files:	hello.hbc (284 bytes) 2019-08-02 20:34 https://bugs.astron.com/file_download.php?file_id=69&type=bug

Notes
(0003282) christos    2019-08-05 13:10	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
80	[tcsh] General	major	always	2019-05-13 18:15	2019-08-02 17:22
Reporter:	mnowak	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	6.21.00
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	gethost: ".../tcsh-6.21.00/host.defs", 36: Discarded
Description:	Build of tcsh 6.21.00 on OpenIndiana 2019.04 (an illumos distribution) fails with: ./gethost /export/home/newman/ws/oi-userland/components/shell/tcsh/tcsh-6.21.00/host.defs >> tc.defs.c.tmp gethost: "/export/home/newman/ws/oi-userland/components/shell/tcsh/tcsh-6.21.00/host.defs", 36: Discarded gethost: "/export/home/newman/ws/oi-userland/components/shell/tcsh/tcsh-6.21.00/host.defs", 47: Discarded ... gethost: "/export/home/newman/ws/oi-userland/components/shell/tcsh/tcsh-6.21.00/host.defs", 349: Discarded gethost: "/export/home/newman/ws/oi-userland/components/shell/tcsh/tcsh-6.21.00/host.defs", 350: Discarded gethost: Too many errors make[1]: *** [Makefile:455: tc.defs.c] Error 1 Full build output is in the attached file. tcsh-6.20.00 builds fine. Let me know, should you need more information.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	tcsh.txt (22,330 bytes) 2019-05-13 18:15 https://bugs.astron.com/file_download.php?file_id=54&type=bug

Notes
(0003253) mnowak    2019-06-15 14:09	Reported also at https://github.com/tcsh-org/tcsh/issues/14.
(0003271) christos    2019-08-01 14:03	I built it with both cc and gcc and no issues: christos@openindiana:~/src/tcsh$ cc -V cc: Sun C 5.10 SunOS_i386 2009/06/03 usage: cc [ options] files. Use 'cc -flags' for details christos@openindiana:~/src/tcsh$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/gcc/8/lib/gcc/i386-pc-solaris2.11/8.3.0/lto-wrapper Target: i386-pc-solaris2.11 Configured with: /jenkins/jobs/oi-userland/workspace/components/developer/gcc-8/gcc-8.3.0/configure CC=/usr/gcc/6/bin/gcc CXX=/usr/gcc/6/bin/g++ F77=/usr/gcc/6/bin/gfortran FC=/usr/gcc/6/bin/gfortran CFLAGS= CXXFLAGS= FFLAGS=' -m32 -O3 ' FCFLAGS='-m32 -O3 ' LDFLAGS=-m32 PKG_CONFIG_PATH=/usr/lib/pkgconfig --prefix=/usr/gcc/8 --mandir=/usr/gcc/8/share/man --bindir=/usr/gcc/8/bin --libdir=/usr/gcc/8/lib --sbindir=/usr/gcc/8/sbin --sbindir=/usr/gcc/8/bin --libdir=/usr/gcc/8/lib --libexecdir=/usr/gcc/8/lib --host i386-pc-solaris2.11 --build i386-pc-solaris2.11 --target i386-pc-solaris2.11 --with-pkgversion='OpenIndiana 8.3.0-OI-0' --with-bugurl=https://bugs.openindiana.org --enable-plugins --enable-objc-gc --enable-initfini-array --enable-languages=c,c++,fortran,lto,objc --without-gnu-ld --with-ld=/usr/bin/ld --with-build-time-tools=/usr/gnu/i386-pc-solaris2.11/bin --disable-libitm enable_frame_pointer=yes --with-gnu-as --with-as=/usr/bin/gas 'BOOT_CFLAGS=-g -O2' LDFLAGS=-R/usr/gcc/8/lib Thread model: posix gcc version 8.3.0 (OpenIndiana 8.3.0-OI-0) christos@openindiana:~/src/tcsh$
(0003272) christos    2019-08-01 14:07	Cannot reproduce.
(0003274) mnowak    2019-08-01 14:47	Right, thanks for looking into this. GCC 8.3.0 works for me as well. Is GCC 8 now required? By default we use GCC 6.5.0. GCC 7.4.0 fails for me the same way GCC 6 does.
(0003275) christos    2019-08-01 15:36	No, I've built it before with gcc-5, gcc-6, gcc-7... I think something might be wrong with the opensolaris gcc packages of gcc-6/7...
(0003277) christos    2019-08-01 16:06	I will resolve it since it seems like a compiler/environment-specific bug. Don't you agree?
(0003280) mnowak    2019-08-02 17:10	It's actually the -O3 optimization we use by default, with -O2 we are good. I think you can close this. Thanks!
(0003281) christos    2019-08-02 17:22	gcc optimizer bug.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
94	[tcsh] General	crash	always	2019-07-26 21:38	2019-08-01 14:18
Reporter:	swagstafff	Platform:	Mac
Assigned To:	christos	OS:	macOS
Priority:	normal	OS Version:	10.14
Status:	resolved	Product Version:	6.21.00
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	6.22.00
		Target Version:
Summary:	Apple patches not applied
Description:	Apple has patched its Mac OS X/macOS tcsh installations [1] since c. 2007 [2]. These patches have never propagated upstream and lead to bugs when not applied on a Mac. Bugs include incorrect HOSTTYPE, OSTYPE, MACHTYPE; and crash with segmentation fault. [1] https://opensource.apple.com/source/tcsh/ [2] https://opensource.apple.com/source/tcsh/tcsh-60/patches/
Tags:
Steps To Reproduce:	host.defs.patch Unpatched: > echo $HOSTTYPE $OSTYPE $MACHTYPE unknown bsd44 unknown After patch (and expected): > echo $HOSTTYPE $OSTYPE $MACHTYPE intel-mac darwin x86_64 Before config_f.h.patch: > nonexistent > /dev/null nonexistent: Command not found. Segmentation fault
Additional Information:	The uploaded files incorporate Apple's latest patches ("tcsh-67") [3], with some adaptation for application to tcsh 6.21.00 and corrections for correct hosttype on Intel Macs. The patches have been tested on macOS 10.12.6 and 10.14.5. [3] https://opensource.apple.com/source/tcsh/tcsh-67/patches/
Attached Files:	config_f.h.patch (279 bytes) 2019-07-26 21:38 https://bugs.astron.com/file_download.php?file_id=65&type=bug host.defs.patch (678 bytes) 2019-07-26 21:38 https://bugs.astron.com/file_download.php?file_id=66&type=bug tc.sig.h.patch (456 bytes) 2019-07-26 21:38 https://bugs.astron.com/file_download.php?file_id=67&type=bug

Notes
(0003273) christos    2019-08-01 14:18	Applied (except the KAI one, which is not appropriate).

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
58	[tcsh] General	minor	N/A	2019-01-30 01:12	2019-08-01 07:29
Reporter:	PesoMemo	Platform:	PC
Assigned To:	christos	OS:	Windows
Priority:	normal	OS Version:	10
Status:	feedback	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Unable to find pre-compiled tcsh64.exe or tcsh86.exe for tcsh version 6.20.00
Description:	I've searched for hours to no avail - does anyone know where I can D/L a Windows 10 binary x64/x86 of tcsh 6.20.00 ? If anyone has a copy can they post it to a URL/share site where I can D/L it? TIA, Bill PS: You can email me at PesoMemo <atsign> gmail.com
Tags:	tcsh64.exe tcsh86.exe tcsh 6.20.00 windows
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003270) christos    2019-08-01 07:29	Sorry, I don't have a setup to build. Amol, used to provide the binaries. Please ask in the mailing lists.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
81	[tcsh] General	major	always	2019-05-17 13:58	2019-07-29 13:05
Reporter:	oldpink	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	6.21.00
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	6.22.00
		Target Version:
Summary:	Filename expansion inside square brackets is apparently broken
Description:	I have been running TCSH version 6.21.00 on my Slackware system since Patrick Volkderding made the new build of TCSH part of Slackware-current on May 10. However, I ran into a really nasty issue with this new version of TCSH that breaks filename pattern matching within square brackets, specifically, I tried upgrading (via upgradepkg) several of my Slackware packages selectively by excluding some of the packages that I had downloaded so that I could install the excluded packages as additions instead of upgrading them. I excluded the kernel packages, using the following command: upgradepkg [b-c,l-z]*.t?z However, much to my dismay, it went ahead and upgraded the kernel-* packages anyway, deleting my three already installed kernel packages that I wanted to keep in place as secondary bootup and backups. Sure enough, when I type "ls [b-c,l-z]*.t?z, it includes the kernel-* files in the list of files, too. Obviously, this is not the way it should work, so I downloaded version 6.21.00 from source, then compiled it using the Slackware build script (called a SlackBuild) to see if reverting the previous kernel would correct the error, and Shazam! yes it works as it should, properly excluding the kernel-* files in my filespec. I'm certain that this is a bug, and a very bad one at that, so I'll be using the previous version of TCSH for now, but I wanted to let you know about my problem with the current version so that maybe something could be done before someone unintentionally wipes out an entire file system or something else because of this bug.
Tags:
Steps To Reproduce:	Here is the list of files I'm trying to exclude, with no other files in the directory where they are: kernel-huge-4.19.44-x86_64-1.txz kernel-source-4.19.44-noarch-1.txz kernel-modules-4.19.44-x86_64-1.txz Using Bash, I get the proper response with this command: ls [a-d,l-z]* ls: cannot access '[a-d,l-z]*': No such file or directory Using version 6.20.00 of TCSH: ls [a-d,l-z]* /bin/ls: No match. Using the buggy version 6.21.00 version of TCSH: ls [a-d,l-z]* kernel-huge-4.19.44-x86_64-1.txz kernel-source-4.19.44-noarch-1.txz kernel-modules-4.19.44-x86_64-1.txz Clearly something is not right.
Additional Information:
Attached Files:

Notes
(0003246) oldpink    2019-05-17 14:04	I made a typo, and I can't find a way to edit my original bug report, so I'm writing my correction down here in the note box to explain that I downloaded the source and built version 6.20.00, NOT 6.21.00 to see if the bug went away by using the previous TCSH. Sorry about my error.
(0003269) christos    2019-07-29 13:05	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
93	[file] General	minor	always	2019-07-17 17:52	2019-07-23 08:51
Reporter:	iaeiaeiaeiae@byom.de	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:	5.37
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	file incorrectly recognizes -static-pie binaries
Description:	file recognizes binaries build with gcc using -static-pie as dynamically linked binaries.
Tags:
Steps To Reproduce:	1. Create a simple hello word C program 2. Compile it using gcc -fPIE -static-pie -o test test.c 3. Run file on the resulting binary Output: test: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=4594afb38f3f60aaad10d08ab519fcaeae55ee70, for GNU/Linux 3.2.0, not stripped It should actually be reported as statically linked, check with ldd: $ ldd test     statically linked
Additional Information:
Attached Files:	testbin (806,560 bytes) 2019-07-22 18:29 https://bugs.astron.com/file_download.php?file_id=64&type=bug

Notes
(0003260) christos    2019-07-21 09:05	I can't reproduce this [5:04am] 10020>cc -static -fPIE -pie hello.c -o hello [5:04am] 10021>./file -m ../magic/magic.mgc ./hello ./hello: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.32, BuildID[sha1]=f864bee36ab81bd40145389b987e8fe6b6d92696, not stripped [5:04am] 10022>./file --version file-5.37 magic file from /usr/local/share/misc/magic
(0003266) iaeiaeiaeiae@byom.de    2019-07-22 18:29	"-static -pie" and "-static-pie" are not the same thing. You need a relatively recent gcc for the latter https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=252034 I used gcc (GCC) 9.1.0.
(0003267) christos    2019-07-22 20:43	I don't have an environment like that available. Can you just attach a binary?
(0003268) iaeiaeiaeiae@byom.de    2019-07-23 08:51	The previous comment contained a binary. https://bugs.astron.com/file_download.php?file_id=64&type=bug

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
68	[file] General	feature	have not tried	2019-02-24 16:23	2019-07-21 18:31
Reporter:	valoq	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Native decompression formats
Description:	Note: This is a copy of the original issue (https://bugs.astron.com/view.php?id=3) without the spam. Currently file uses external applications to decompress certain file formats before analysing them. This prevents effective sandboxing via seccomp. This bug is to collect information and keep track of the progress of implementing all compression formats using libraries Currently we have the folloging native decompression functions: uncompressgzipped uncompresszlib The following external decompression tools are currently used and need to be implemented using their respective libraries: gzip uncompress bzip2 lzip xz lrzip lz4 zstd Additional information: most of the necessary source code can be found here: https://nxr.netbsd.org/search?q=&project=src&defs=&refs=&path=usr.bin%2Fgzip&hist= (thanks christos)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003223) valoq    2019-02-24 16:27	@christos: Do you want all compression to be handled within compress.c (using only this one file) or can we use additional files for each compression algorithm? Also, it seems I cannot close my own issues, so if possible please close the old one: https://bugs.astron.com/view.php?id=3
(0003224) christos    2019-02-24 18:09	I think each compression scheme can come in its own file and this way we can probably use an adapter so we don't have to modify all sources.
(0003226) valoq    2019-02-24 22:18	After taking a look at the bsd implementations, I think we can at least use the xz (unxz.c) decompression and the bzip (unbzip2.c) decompression code.                                                                                                                                                                                                                  One issue remaining is that they use file descriptors for in and output and not strings. I am not quite sure how we should adapt the code to be used by file. Also I still don't completely understand some of the decompression handling of file. Since I am not an expert on C I am rather reluctant to mess with stuff like that, especially since it involves a widely used program like file. Nonetheless I am looking to push this to get a working implementation of seccomp into file (Debian buster just disabled seccomp as well :( )
(0003228) valoq    2019-03-03 14:56	@christos: Can you please provide the adapter to allow for easier adoption of third party compression code. That would be a great help.
(0003265) christos    2019-07-21 18:31	bzip, lzma, xz added by Christoph Biedl

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
92	[file] General	minor	always	2019-07-17 14:46	2019-07-21 09:59
Reporter:	ulm	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.37
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.38
		Target Version:
Summary:	file-5.37 falsely identifies text file (PSF license) as audio/x-psf
Description:	$ file -i PSF-2.2 PSF-2.2: audio/x-psf; charset=us-ascii $ head -n1 PSF-2.2 PSF LICENSE AGREEMENT FOR PYTHON 2.2 file-5.36 had correctly identified the same file as "text/plain; charset=us-ascii". Full file is here: https://gitweb.gentoo.org/repo/gentoo.git/plain/licenses/PSF-2.2
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003264) christos    2019-07-21 09:59	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
91	[file] General	minor	always	2019-07-09 02:20	2019-07-21 09:40
Reporter:	avellable	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.33
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.38
		Target Version:
Summary:	Ruby files are detected properly when require contains '.'
Description:	Magic test fails to detect ruby file if there's a '.' in "require" statement. That is a valid statement.
Tags:
Steps To Reproduce:	Sample File 1. Create a file application.rb # application.rb require './something.rb' 2. Run file on it $ file application.rb application.rb: ASCII text Expected Result: application.rb: Ruby script text, ASCII text Actual Result: application.rb: ASCII text
Additional Information:	Solution: The regex needs to include periods('.') too, See attached fixed file for reference. When used, $ file -m new_ruby application.rb application.rb: Ruby script text, ASCII text $ diff new_ruby /usr/share/file/magic/ruby 25c25 < 0 regex \^[[:space:]]*require[[:space:]]'[A-Za-z_/\.]+' --- > 0 regex \^[[:space:]]*require[[:space:]]'[A-Za-z_/]+' 48c48 < 0 regex \^[[:space:]]*require[[:space:]]'[A-Za-z_/\.]+' Ruby script text --- > 0 regex \^[[:space:]]*require[[:space:]]'[A-Za-z_/]+' Ruby script text
Attached Files:	new_ruby (1,812 bytes) 2019-07-09 02:20 https://bugs.astron.com/file_download.php?file_id=63&type=bug

Notes
(0003259) avellable    2019-07-09 02:21	I would be more than happy to create a patch. Is there a document about how to contribute?
(0003263) christos    2019-07-21 09:40	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
89	[file] General	minor	have not tried	2019-06-28 15:58	2019-07-21 09:22
Reporter:	vitalyisaev2	Platform:	amd64
Assigned To:	christos	OS:	Linux
Priority:	normal	OS Version:	Fedora 29
Status:	feedback	Product Version:	5.37
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	MIME Types for PKI files
Description:	I believe that libmagic should support MIME type detection for PKI files, like ".key", ".crt" and so on: application/pkcs8 .p8 .key application/pkcs10 .p10 .csr application/pkix-cert .cer application/pkix-crl .crl application/pkcs7-mime .p7c application/x-x509-ca-cert .crt .der application/x-x509-user-cert .crt application/x-pkcs7-crl .crl application/x-pem-file .pem application/x-pkcs12 .p12 .pfx application/x-pkcs7-certificates .p7b .spc application/x-pkcs7-certreqresp .p7r Please see full list here: https://pki-tutorial.readthedocs.io/en/latest/mime.html
Tags:
Steps To Reproduce:	Currently some of certificates are determined as "plain/text": ➜ file --mime-type ca.crt ca.crt: text/plain ➜ file ca.crt ca.crt: PEM certificate
Additional Information:
Attached Files:	ca.crt (1,302 bytes) 2019-06-28 15:58 https://bugs.astron.com/file_download.php?file_id=58&type=bug

Notes
(0003261) christos    2019-07-21 09:22	Can you try writing a patch for this? I am not sure if we can cover most of the cases because we don't know enough about what the files contain (and file does not pay attention to extensions).

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
82	[file] General	feature	N/A	2019-05-25 23:03	2019-07-04 18:54
Reporter:	GerbilSoft	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.37
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.38
		Target Version:
Summary:	Xbox, Xbox 360, VGM, and SNDH improvements
Description:	This is a small patch set with the following improvements: Audio: - VGM: Added YMZ284 and YMZ294 variants for AY-3-8910. - SNDH: Added a check for ICE-compressed files. Xbox: - Added MIME types and file extensions for XBE and XEX files. - XEX: Display the 32-bit media ID. - XEX: Support XEX1 format. (early devkits) - Added Xbox 360 packages. (from Xbox Live and/or system updates)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	file.2019-05-25.19-00.tar.gz (3,282 bytes) 2019-05-25 23:03 https://bugs.astron.com/file_download.php?file_id=55&type=bug

Notes
(0003248) christos    2019-05-27 01:35	Added, thanks.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
84	[file] General	minor	have not tried	2019-06-03 11:35	2019-06-28 15:48
Reporter:	vitalyisaev2	Platform:	amd64
Assigned To:	christos	OS:	Linux
Priority:	normal	OS Version:	Fedora 29
Status:	assigned	Product Version:	5.36
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Wrong mime-type for audio wma file
Description:	Hello, could you please check this audio file. It's defined as `video/x-ms-asf`, though it contains only music. $ file Amy\&Amethyst.wma --mime-type Amy&Amethyst.wma: video/x-ms-asf $ file --version file-5.36 magic file from /etc/magic:/usr/share/misc/magic
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	Amy&Amethyst.wma (140,547 bytes) 2019-06-03 11:35 https://bugs.astron.com/file_download.php?file_id=57&type=bug

Notes
(0003249) vitalyisaev2    2019-06-03 12:17	Expected: audio/x-ms-wma
(0003252) christos    2019-06-08 22:41	ASF is a container format that can contain various media files such as WMA (https://en.wikipedia.org/wiki/Advanced_Systems_Format) file(1) does not know how to look inside (yet)
(0003257) vitalyisaev2    2019-06-28 15:48	If I find some who is aware of video streaming / codec, I will try to ask, how they detect what's inside ASF.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
86	[file] General	minor	always	2019-06-09 13:00	2019-06-16 00:16
Reporter:	Mababa	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	feedback	Product Version:	5.36
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	wrong type reported for text files beginning with the characters "BIK"
Description:	Any text file where the first three characters are "BIK" are reported as "Bink Video". The more text that follows these initial characters, the more bogus information "file" seems to report. $ echo BIK hello | file - /dev/stdin: Bink Video rev.h, 0 audio track $ echo BIKING to work | file - /dev/stdin: Bink Video rev.t, 1870078063 frames, 0 audio track $ echo BIKes have more fun when they sleep | file - /dev/stdin: Bink Video rev.e, 1852139639x1701344288, 1830839670 frames at rate 175138149/1819484281, 0 audio track
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003255) christos    2019-06-16 00:16	I made it a bit stronger.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
83	[file] General	minor	always	2019-05-30 20:35	2019-06-08 22:23
Reporter:	j2j	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	feedback	Product Version:	5.37
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Too many false hits "(Lepton " by Magdir/measure
Description:	Hello, when i run file command version 5.37 and some earlier versions on many files with -k option i often get also misidentification messages starting with "(Lepton 3.x)" or "(Lepton 2.x)". See appended output fileLepton.txt. When looking inside sources i see that such messages are triggered by magic lines inside Magdir/measure. These magic lines should identify DIY-Thermocam raw data files. Apparently such file have no real magic patterns. So test for values in some range is done by lines like      9608 ubyte <19      >9 ubyte <2 But these test lines are too generic or not precise. These tests are also matched by ISO 9660 CD-ROM images and many other file types. So more test lines are needed. Unfortunately no contributor name or web site is mentioned. So i have no information about that file format to fix weak magic lines.
Tags:	magic
Steps To Reproduce:
Additional Information:
Attached Files:	fileLepton.txt (34,203 bytes) 2019-05-30 20:35 https://bugs.astron.com/file_download.php?file_id=56&type=bug

Notes
(0003251) christos    2019-06-08 22:23	Do you have a file I can check against? It does try 5 different byte values in the checker...

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
85	[file] General	minor	have not tried	2019-06-05 11:09	2019-06-08 22:18
Reporter:	vitalyisaev2	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.36
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.38
		Target Version:
Summary:	Support CSV detection
Description:	It would be nice if we could distinguish csv files from other ASCII text files. It may be tricky, but perhaps we can rely on the number of commas and other widely used delimiters. If the amount of delimiters is same for the first N lines, it's like to be a csv file. This tread may be also useful: https://www.unix.com/shell-programming-and-scripting/25477-how-validate-csv-file.html Kind regards, Vitaly
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003250) christos    2019-06-08 22:18	Added...

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
79	[file] General	feature	N/A	2019-05-10 03:52	2019-05-27 01:28
Reporter:	cisba	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.38
		Target Version:
Summary:	[PATCH] add OpenTimestamps related magic entries
Description:	https://opentimestamps.org/ https://en.wikipedia.org/wiki/OpenTimestamps
Tags:	magic
Steps To Reproduce:	1. create a file .ots using the web interface at https://opentimestamps.org/ 2. download the attacched file "opentimestamps" 3. execute "file -m opentimestamps <your-ots-file-name>.ots"
Additional Information:
Attached Files:	opentimestamps (647 bytes) 2019-05-10 03:52 https://bugs.astron.com/file_download.php?file_id=53&type=bug

Notes
(0003247) christos    2019-05-27 01:28	Added, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
74	[tcsh] General	major	always	2019-03-25 09:51	2019-05-08 18:06
Reporter:	bitstreamout	Platform:
Assigned To:	christos	OS:	Linux
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	6.21.00
		Target Version:
Summary:	Bug in tcsh postcmd alias handling
Description:	The postcmd alias destroys boolean handling withing loops
Tags:
Steps To Reproduce:	simple script to test this on tcsh 6.18.0 as well as on 6.20.0  # !/bin/tcsh  alias postcmd false  set counter=5  while ($counter > 0)    @ counter--    echo $counter    sleep 1  end  exit 0 ... this should break for counter getting 0 but it does not
Additional Information:
Attached Files:	debug (1,613 bytes) 2019-04-05 09:16 https://bugs.astron.com/file_download.php?file_id=47&type=bug tcsh-postcmd.patch (3,043 bytes) 2019-04-08 11:38 https://bugs.astron.com/file_download.php?file_id=48&type=bug tcsh-6.20.00-postcmd.patch (1,421 bytes) 2019-04-09 07:25 https://bugs.astron.com/file_download.php?file_id=49&type=bug

Notes
(0003232) bitstreamout    2019-04-05 09:16	Hmmm .. .after some debugging it looks like the function dowhile() of sh.func.c is executed repeated if no postcmd alias is set whereas if one is set the dowhile() is reached only once and does never finish
(0003233) bitstreamout    2019-04-05 12:56	The bug is also in tcsh-6.16.00
(0003238) bitstreamout    2019-04-08 11:38	Looks like aliasrun() does destroy the current parse tree .... at least this patch make the test case work
(0003239) bitstreamout    2019-04-09 07:25	This one avoids breaking the testsuit
(0003245) christos    2019-05-08 18:06	Thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
78	[file] General	minor	have not tried	2019-05-07 11:32	2019-05-08 18:02
Reporter:	jpcima	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.37
		Target Version:
Summary:	[PATCH] add BambooTracker instrument, and version number detection
Description:	Patch: https://github.com/file/file/compare/master...jpcima:bamboo-tracker.diff Adds support for BTI files (instruments). Extracts the version number from uint32 BCD field. -> specification at https://github.com/rerrahkr/BambooTracker/tree/master/specs
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	Echo Piano Bell.bti (106 bytes) 2019-05-07 11:32 https://bugs.astron.com/file_download.php?file_id=52&type=bug

Notes
(0003244) christos    2019-05-08 18:02	thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
73	[file] General	minor	always	2019-03-20 09:21	2019-04-09 18:34
Reporter:	enkeli	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.36
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.37
		Target Version:
Summary:	Reports Zip archive data for data with only one PK central dir signature
Description:	File reports for the attached file "Zip archive data". $ file data-not-zip data-not-zip: Zip archive data The only ZIP-like thing it contains is 0x06054b50 and it does not seem sufficient to me to mark it as ZIP. File hexdump: 00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................ file v. 5.30 reports "data" which seems more precise to me 00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000040: 0000 0000 0000 0000 0050 4b05 0600 0000 .........PK..... 00000050: 0000 0000 0000 0000 0000 0000 0000 000a ................
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	data-not-zip (408 bytes) 2019-03-20 09:21 https://bugs.astron.com/file_download.php?file_id=46&type=bug data-not-zip-2 (102 bytes) 2019-04-09 09:32 https://bugs.astron.com/file_download.php?file_id=51&type=bug

Notes
(0003235) christos    2019-04-07 18:23	Can't reproduce it: [2:20pm] 2551>xxd -r ../data-not-zip >! ../data [2:20pm] 2552>src/file -m magic/magic.mgc data data: data [2:20pm] 2553>hexdump -C data 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000040 00 00 00 00 00 00 00 00 00 50 4b 05 06 00 00 00 |.........PK.....| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0a |................| 00000060 [2:20pm] 2554>src/file -v file-5.36 magic file from /usr/local/share/misc/magic
(0003240) enkeli    2019-04-09 09:32	Sorry, I've probably uploaded wrong file. This one is definitely reported as ZIP (close this issue if I'm wrong). I'd expect "data" or something other than ZIP. $ sha256sum data-not-zip a95a3e433275508dfbcfbea7ba83ff6b69d582be25dd0f3a87e2e9739b735d34 data-not-zip $ file --version file-5.36 magic file from /usr/share/file/misc/magic $ file data-not-zip data-not-zip: Zip archive data
(0003242) christos    2019-04-09 18:34	Fixed, thanks

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
76	[file] General	minor	always	2019-04-09 09:18	2019-04-09 18:29
Reporter:	mohd-akram	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.36
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.37
		Target Version:
Summary:	[PATCH] Fix Python 3.7 byte-compiled detection
Description:	Should be checking 0x420d0d0a not 0x3e0d0d0a. See https://github.com/python/cpython/blob/3.7/Lib/importlib/_bootstrap_external.py#L259.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	patch-python37.diff (466 bytes) 2019-04-09 09:18 https://bugs.astron.com/file_download.php?file_id=50&type=bug

Notes
(0003241) christos    2019-04-09 18:29	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
71	[file] General	major	always	2019-03-12 13:10	2019-04-07 18:28
Reporter:	edurdo100	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	feedback	Product Version:	5.33
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Problem with encoding of file larger than 262145 characterers
Description:	Whe run command file with the next options: file -bi $fichero In case than file larger than 262145 encoding always appear us-ascii, when the file has the encoding iso-8859-1
Tags:
Steps To Reproduce:	Create a file encoding like iso-8859-1 and more than 262145 characterers Run command: file -bi $fichero
Additional Information:
Attached Files:

Notes
(0003237) christos    2019-04-07 18:28	Can you attach an example? Does the behavior change when you use -P bytes to a large number?

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
72	[file] General	minor	always	2019-03-20 01:54	2019-04-07 18:26
Reporter:	tduffy	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.36
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.37
		Target Version:
Summary:	magic/Magdir/apple reports as data (instead of ASCII)
Description:	$ file magic/Magdir/apple magic/Magdir/apple: data Looks like there are some bogus bytes on line 91: #:apple pdosp^Zøÿ
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003236) christos    2019-04-07 18:26	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
75	[file] General	minor	always	2019-03-31 19:16	2019-04-07 18:05
Reporter:	wylda	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.36
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.37
		Target Version:
Summary:	file-5.36: configure --enable-zlib actually disables Zlib
Description:	If "--enable-zlib" is explicitly given for configure, then "ZLIBSUPPORT" won't be set to 1, even if in my case I have: enable_zlib=yes ac_cv_header_zlib_h=yes ac_cv_lib_z_gzopen=yes I'm not a programmer, but i guess it is because of "elif" instead of "if"??? ---snip--- if test "$enable_zlib" = "yes"; then   if test "$ac_cv_header_zlib_h$ac_cv_lib_z_gzopen" != "yesyes"; then     as_fn_error $? "zlib support requested but not found" "$LINENO" 5   fi elif test "$ac_cv_header_zlib_h$ac_cv_lib_z_gzopen" = "yesyes"; then   $as_echo "#define ZLIBSUPPORT 1" >>confdefs.h fi ---snip---
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003234) christos    2019-04-07 18:05	Fixed, thanks.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
70	[file] General	feature	always	2019-03-05 17:33	2019-03-07 17:22
Reporter:	v3l0c1r4pt0r	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.37
		Target Version:
Summary:	[PATCH] Add AIX backup and package format detection
Description:	I have noticed that AIX default package format is not identified by file ("data" returned). I am enclosing the patch. I've managed to find example package with first signature variant (could be downloaded from IBM after signing up). Unfortunately I didn't find any example for the second form (confirmed only with Wikipedia and original AIX /etc/magic).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	0001-Add-AIX-package-and-backup-file-magic.patch (766 bytes) 2019-03-05 17:33 https://bugs.astron.com/file_download.php?file_id=45&type=bug

Notes
(0003229) christos    2019-03-07 13:22	both magic entries have the same description, is that correct?
(0003230) v3l0c1r4pt0r    2019-03-07 14:41	Yes, that's correct. I haven't seen any explanation of what is the difference.
(0003231) christos    2019-03-07 17:22	Committed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
69	[file] General	major	always	2019-02-27 16:04	2019-03-02 01:08
Reporter:	vinc17	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.35
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.37
		Target Version:
Summary:	mistakes Xorg.0.log file as JSON data
Description:	file mistakes Xorg.0.log file as JSON data (which breaks viewing with "less" + LESSOPEN).
Tags:
Steps To Reproduce:	Example on the first 5 lines: [105215.998] X.Org X Server 1.20.3 X Protocol Version 11, Revision 0 [105215.998] Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian [105215.998] Current Operating System: Linux cventin 4.19.0-3-amd64 0000001 SMP Debian 4.19.20-1 (2019-02-11) x86_64 $ file Xorg.0.log Xorg.0.log: JSON data
Additional Information:	Also reported on the Debian BTS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922874
Attached Files:

Notes
(0003227) christos    2019-03-02 01:08	Changed to be stricter.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
66	[file] General	feature	N/A	2019-02-20 23:47	2019-02-23 01:17
Reporter:	GerbilSoft	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.37
		Target Version:
Summary:	Another batch of patches for various game console formats
Description:	This patchset adds the following formats: - Scaleform video (basic identification only) - PowerVR 3.0 textures - Portable Sound Format (PSF) - SAP (Atari 8-bit audio) - Nintendo audio formats: BRSTM, BCSTM, BFSTM, BCWAV - Xbox XPR0 textures - Xbox 360 executables (XEX) Other changes: - ADX: Added a MIME type; prevent conflicts with Targa images; fix AHX and add AHX (Dreamcast). - GameCube, Wii: Added unofficial MIME types. - Xbox executables (XBE): Show the game title and title ID. - Khronos KTX: Correctly escape the '^' for khronos-ktx-endian-header.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	file.2019-02-20.18-40.tar.gz (9,531 bytes) 2019-02-20 23:47 https://bugs.astron.com/file_download.php?file_id=44&type=bug

Notes
(0003221) christos    2019-02-23 01:17	Committed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
61	[file] General	minor	always	2019-02-15 04:34	2019-02-19 20:35
Reporter:	tmc	Platform:
Assigned To:	christos	OS:	GNU/Linux
Priority:	normal	OS Version:
Status:	feedback	Product Version:	5.35
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Line endings misdetected for UTF16 files
Description:	file misidentifies the line endings of little-endian UTF16 files (running on x86_64), while big-endian seems to work fine. Also it doesn't seem to even try to to identify the line ending of an UTF32 file. Also, I notice that file can't recognise UTF16/32 files without a BOM, which is a pity.
Tags:
Steps To Reproduce:	file misdetects utf16le with CRLF line endings sometimes as CR line endings: > printf "\xff\xfe\r\0\n\0" |file - /dev/stdin: Little-endian UTF-16 Unicode text, with CR line terminators ...and sometimes as mixed CR, CRLF line endings: > printf "\xff\xfe\r\0\n\0\r\0\n\0" |file - /dev/stdin: Little-endian UTF-16 Unicode text, with CRLF, CR line terminators Maybe it's skipping over the final \n? This example reinforces that idea: > printf "\xff\xfe\n\0\r\0" | file - /dev/stdin: Little-endian UTF-16 Unicode text utf16be doesn't seem to show this problem: > printf "\xfe\xff\0\r\0\n" | file - /dev/stdin: Big-endian UTF-16 Unicode text, with CRLF line terminators UTF32 line endings not identified: > printf "\xff\xfe\0\0\r\0\0\0B\0\0\0" | file - /dev/stdin: Unicode text, UTF-32, little-endian
Additional Information:
Attached Files:

Notes
(0003210) christos    2019-02-18 17:04	Yes, the utf-16 detection had length issues, which have been fixed on HEAD. Now the utf-32 detection is not built-in and it is done in regular magic, this is why it does not get the CR/LF info right. I guess we should move the utf-32 detection to be built-in for consistency. Here's the latest output: [11:59am] 2601>cat uni #!/bin/sh doit() {         printf "$1" | ./file -m ../magic//magic.mgc - } doit "\xff\xfe\r\0\n\0" doit "\xff\xfe\r\0\n\0\r\0\n\0" doit "\xff\xfe\n\0\r\0" doit "\xfe\xff\0\r\0\n" doit "\xff\xfe\0\0\r\0\0\0B\0\0\0" [11:59am] 2602>./uni /dev/stdin: Little-endian UTF-16 Unicode text, with CRLF line terminators /dev/stdin: Little-endian UTF-16 Unicode text, with CRLF line terminators /dev/stdin: Little-endian UTF-16 Unicode text, with CR, LF line terminators /dev/stdin: Big-endian UTF-16 Unicode text, with CRLF line terminators /dev/stdin: Unicode text, UTF-32, little-endian
(0003220) christos    2019-02-19 20:35	Should be fixed now: #!/bin/sh doit() {         printf "$1" | ./file -m /dev/null - } doit "\xff\xfe\r\0\n\0" doit "\xff\xfe\r\0\n\0\r\0\n\0" doit "\xff\xfe\n\0\r\0" doit "\xfe\xff\0\r\0\n" doit "\xff\xfe\0\0\r\0\0\0B\0\0\0" doit "\xff\xfe\0\0\r\0\0\0\n\0\0\0" doit "\0\0\xfe\xff\0\0\0\r\0\0\0\n"

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
64	[file] General	major	always	2019-02-18 08:50	2019-02-19 13:21
Reporter:	spinpx	Platform:	x86_64
Assigned To:	christos	OS:	Debian
Priority:	urgent	OS Version:	10
Status:	resolved	Product Version:	5.35
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.36
		Target Version:
Summary:	ASAN: memcpy-param-overlap
Description:	描述 We build file with `--disable-libseccomp` by clang 4.0.0 and ASAN. We ran the program with the input we provide without any other arguments. The bugs exists in file 5.35. ASAN report: ==1129930==ERROR: AddressSanitizer: memcpy-param-overlap: memory ranges [0x7ffcc4a0f360,0x7ffcc4a10861) and [0x7ffcc4a104f8, 0x7ffcc4a119f9) overlap     #0 0x4add33 in __asan_memcpy /scratch/llvm/clang-4/xenial/final/llvm.src/projects/compiler-rt/lib/asan/asan_interceptors.cc:453:3     0000001 0x54f86c in do_core_note /mnt/raid/user/chenpeng/FuzzingBench/file/file/src/readelf.c:755:4     0000002 0x54d323 in donote /mnt/raid/user/chenpeng/FuzzingBench/file/file/src/readelf.c:1194:7     0000003 0x54792a in dophn_core /mnt/raid/user/chenpeng/FuzzingBench/file/file/src/readelf.c:398:13     0000004 0x5451b4 in file_tryelf /mnt/raid/user/chenpeng/FuzzingBench/file/file/src/elfclass.h:43:7     0000005 0x51f29b in file_buffer /mnt/raid/user/chenpeng/FuzzingBench/file/file/src/funcs.c:305:8     0000006 0x4f5b5d in file_or_fd /mnt/raid/user/chenpeng/FuzzingBench/file/file/src/magic.c:508:6     0000007 0x4f5cd6 in magic_file /mnt/raid/user/chenpeng/FuzzingBench/file/file/src/magic.c:397:9     0000008 0x4f3fd5 in process /mnt/raid/user/chenpeng/FuzzingBench/file/file/src/file.c:546:9     #9 0x4f1c4b in main /mnt/raid/user/chenpeng/FuzzingBench/file/file/src/file.c:416:9     0000010 0x7fbb0e64b09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)     0000011 0x41d689 in _start (/mnt/raid/user/chenpeng/FuzzingBench/build/asan/install/bin/file+0x41d689) Address 0x7ffcc4a0f360 is located in stack of thread T0 at offset 608 in frame     #0 0x54f33f in do_core_note /mnt/raid/user/chenpeng/FuzzingBench/file/file/src/readelf.c:710   This frame has 2 object(s):     [32, 544) 'sbuf'     [608, 768) 'pi' <== Memory access at offset 608 partially overflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext       (longjmp and C++ exceptions *are* supported) Address 0x7ffcc4a104f8 is located in stack of thread T0 at offset 1592 in frame     #0 0x546f7f in dophn_core /mnt/raid/user/chenpeng/FuzzingBench/file/file/src/readelf.c:346   This frame has 3 object(s):     [32, 64) 'ph32'     [96, 152) 'ph64'     [192, 8384) 'nbuf' <== Memory access at offset 1592 is inside this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext       (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: memcpy-param-overlap /scratch/llvm/clang-4/xenial/final/llvm.src/projects/compiler-rt/lib/asan/asan_interceptors.cc:453:3 in __asan_memcpy
Tags:
Steps To Reproduce:	run: # file sbo3
Additional Information:
Attached Files:	sbo3 (9,351 bytes) 2019-02-18 08:50 https://bugs.astron.com/file_download.php?file_id=42&type=bug

Notes
(0003213) christos    2019-02-18 18:00	I think this is the same as PR/63
(0003217) spinpx    2019-02-19 08:12	CVE-2019-8906
(0003219) christos    2019-02-19 13:20	The comment in the CVE is not correct though, it is not memcpy() that causes the overflow; it is the file_printable() that does not work with a non-NUL-terminated string.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
65	[file] General	major	always	2019-02-18 08:53	2019-02-19 13:18
Reporter:	spinpx	Platform:	x86_64
Assigned To:	christos	OS:	Debian
Priority:	urgent	OS Version:	10
Status:	resolved	Product Version:	5.35
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.36
		Target Version:
Summary:	Possible stack corruption
Description:	We build file with `--disable-libseccomp` by clang 4.0.0. We ran the program with the input we provide without any other arguments. The bugs exists in file 5.35. Stack: Program received signal SIGSEGV, Segmentation fault. "#0 0x000000000043e271 in do_core_note (ms=<optimized out>, nbuf=<optimized out>, type=<optimized out>, swap=<optimized out>, namesz=<optimized out>, descsz=<optimized out>, noff=<optimized out>, doff=<optimized out>, flags=<optimized out>, size=<optimized out>, clazz=<optimized out>) at /mnt/raid/user/chenpeng/FuzzingBench/file/file/src/readelf.c:770", 0000001 donote (ms=<optimized out>, vbuf=<optimized out>, offset=3452, size=<optimized out>, clazz=<optimized out>, swap=<optimized out>, align=<optimized out>, flags=<optimized out>, notecount=<optimized out>, fd=<optimized out>, ph_off=<optimized out>, ph_num=<optimized out>, fsize=<optimized out>) at /mnt/raid/user/chenpeng/FuzzingBench/file/file/src/readelf.c:1194 0000002 0x0000000400001000 in ?? () 0000003 0x080490a4000000a4 in ?? () 0000004 0x00bbeaebd9000000 in ?? () 0000005 0x00200001b8000000 in ?? () 0000006 0x0d1263aa87c56e01 in ?? () 0000007 0x2e8ca4eef0bf9884 in ?? () 0000008 0xf8be17bd0299a906 in ?? () #9 0x4fcacce3342026ed in ?? () 0000010 0x0000000100000012 in ?? () 0000011 0x4274654e00000001 in ?? () 0000012 0xcc45524f432d4453 in ?? () 0000013 0x00008990ba88a2ca in ?? () 0000014 0x80e700000004b800 in ?? () 0000015 0x00000000002058eb in ?? () 0000016 0x0000000000000000 in ?? () We run exploitable: Description: Possible stack corruption Short description: PossibleStackCorruption (7/22) Hash: 457b692b06cd893f7646681b5874c47e.57ada0a7199ae15ca6cc5f54cdbeaa99 Exploitability Classification: EXPLOITABLE Explanation: GDB generated an error while unwinding the stack and/or the stack contained return addresses that were not mapped in the inferior's process address space and/or the stack pointer is pointing to a location outside the default stack region. These conditions likely indicate stack corruption, which is generally considered exploitable. Other tags: AccessViolation (21/22)
Tags:
Steps To Reproduce:	run: # file stack_corruption1
Additional Information:
Attached Files:	stack_corruption1 (10,498 bytes) 2019-02-18 08:53 https://bugs.astron.com/file_download.php?file_id=43&type=bug

Notes
(0003214) christos    2019-02-18 18:07	I think this is the same as the other note ones. Can you please try to see if the fix for PR/63 fixed it?
(0003218) spinpx    2019-02-19 08:16	CVE-2019-8907 I verified it with newest git version. It fixed now!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
63	[file] General	major	always	2019-02-18 08:46	2019-02-19 13:17
Reporter:	spinpx	Platform:	x86_64
Assigned To:	christos	OS:	Debian
Priority:	urgent	OS Version:	10
Status:	resolved	Product Version:	5.35
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.36
		Target Version:
Summary:	Stack buffer overflow 2
Description:	We build file with `--disable-libseccomp` by clang 4.0.0 and ASAN. We ran the program with the input we provide without any other arguments. The bugs exists in file 5.35 and the newest git version commit 5b9408cbbd401c13873bf944d3085785547e9915 . ==1104585==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffd001ebb00 at pc 0x00000052240b bp 0x7ffd001eb6c0 sp 0x7ffd001eb6b8 READ of size 1 at 0x7ffd001ebb00 thread T0     #0 0x52240a in file_printable /home/chenpeng/data/FuzzingBench/file/file-git/src/funcs.c:631:57     0000001 0x550158 in do_core_note /home/chenpeng/data/FuzzingBench/file/file-git/src/readelf.c:762:8     0000002 0x54db93 in donote /home/chenpeng/data/FuzzingBench/file/file-git/src/readelf.c:1197:7     0000003 0x549826 in dophn_exec /home/chenpeng/data/FuzzingBench/file/file-git/src/readelf.c:1689:14     0000004 0x545e2d in file_tryelf /home/chenpeng/data/FuzzingBench/file/file-git/src/elfclass.h:58:7     0000005 0x51f29b in file_buffer /home/chenpeng/data/FuzzingBench/file/file-git/src/funcs.c:305:8     0000006 0x4f5b5d in file_or_fd /home/chenpeng/data/FuzzingBench/file/file-git/src/magic.c:508:6     0000007 0x4f5cd6 in magic_file /home/chenpeng/data/FuzzingBench/file/file-git/src/magic.c:397:9     0000008 0x4f3fd5 in process /home/chenpeng/data/FuzzingBench/file/file-git/src/file.c:546:9     #9 0x4f1c4b in main /home/chenpeng/data/FuzzingBench/file/file-git/src/file.c:416:9     0000010 0x7fe9e3d9f09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)     0000011 0x41d689 in _start (/mnt/raid/user/chenpeng/FuzzingBench/build/asan/install/bin/file+0x41d689) Address 0x7ffd001ebb00 is located in stack of thread T0 at offset 768 in frame     #0 0x54fbaf in do_core_note /home/chenpeng/data/FuzzingBench/file/file-git/src/readelf.c:713   This frame has 2 object(s):     [32, 544) 'sbuf'     [608, 768) 'pi' <== Memory access at offset 768 overflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext       (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow /home/chenpeng/data/FuzzingBench/file/file-git/src/funcs.c:631:57 in file_printable Shadow bytes around the buggy address:   0x100020035710: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   0x100020035720: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   0x100020035730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   0x100020035740: 00 00 00 00 f2 f2 f2 f2 f2 f2 f2 f2 00 00 00 00   0x100020035750: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x100020035760:[f3]f3 f3 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00   0x100020035770: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   0x100020035780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   0x100020035790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   0x1000200357a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   0x1000200357b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes):   Addressable: 00   Partially addressable: 01 02 03 04 05 06 07   Heap left redzone: fa   Freed heap region: fd   Stack left redzone: f1   Stack mid redzone: f2   Stack right redzone: f3   Stack after return: f5   Stack use after scope: f8   Global redzone: f9   Global init order: f6   Poisoned by user: f7   Container overflow: fc   Array cookie: ac   Intra object redzone: bb   ASan internal: fe   Left alloca redzone: ca   Right alloca redzone: cb ==1104585==ABORTING
Tags:
Steps To Reproduce:	run: # file sbo2
Additional Information:
Attached Files:	sbo2 (1,192 bytes) 2019-02-18 08:46 https://bugs.astron.com/file_download.php?file_id=41&type=bug

Notes
(0003212) christos    2019-02-18 17:47	Thanks, should be fixed with: /p/file/cvsroot/file/src/file.h,v <-- file.h new revision: 1.202; previous revision: 1.201 /p/file/cvsroot/file/src/funcs.c,v <-- funcs.c new revision: 1.101; previous revision: 1.100 /p/file/cvsroot/file/src/readelf.c,v <-- readelf.c new revision: 1.161; previous revision: 1.160 /p/file/cvsroot/file/src/softmagic.c,v <-- softmagic.c new revision: 1.277; previous revision: 1.276
(0003216) spinpx    2019-02-19 08:12	CVE-2019-8905

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
62	[file] General	major	always	2019-02-18 08:42	2019-02-19 13:16
Reporter:	spinpx	Platform:	Intel
Assigned To:	christos	OS:	Debian
Priority:	urgent	OS Version:	10
Status:	resolved	Product Version:	5.35
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.36
		Target Version:
Summary:	Stack buffer overflow
Description:	We build file with `--disable-libseccomp` by clang 4.0.0 and ASAN. We ran the program with the input we provide without any other arguments. The bugs exists in file 5.35 and the newest git version commit 5b9408cbbd401c13873bf944d3085785547e9915 . ASAN report: ==990598==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffea9a966a0 at pc 0x000000441461 bp 0x7ffea9a931d0 sp 0x7ffea9a92940 READ of size 8167 at 0x7ffea9a966a0 thread T0     #0 0x441460 in printf_common(void*, char const*, __va_list_tag*) /scratch/llvm/clang-4/xenial/final/llvm.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors_format.inc:544:9     0000001 0x442140 in vasprintf /scratch/llvm/clang-4/xenial/final/llvm.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:1412:1     0000002 0x51d538 in file_vprintf /home/chenpeng/data/FuzzingBench/file/file-git/src/funcs.c:62:8     0000003 0x51da90 in file_printf /home/chenpeng/data/FuzzingBench/file/file-git/src/funcs.c:88:7     0000004 0x54f602 in do_bid_note /home/chenpeng/data/FuzzingBench/file/file-git/src/readelf.c:569:7     0000005 0x54d6f9 in donote /home/chenpeng/data/FuzzingBench/file/file-git/src/readelf.c:1185:7     0000006 0x54814a in dophn_core /home/chenpeng/data/FuzzingBench/file/file-git/src/readelf.c:401:13     0000007 0x5459d4 in file_tryelf /home/chenpeng/data/FuzzingBench/file/file-git/src/elfclass.h:43:7     0000008 0x51f29b in file_buffer /home/chenpeng/data/FuzzingBench/file/file-git/src/funcs.c:305:8     #9 0x4f5b5d in file_or_fd /home/chenpeng/data/FuzzingBench/file/file-git/src/magic.c:508:6     0000010 0x4f5cd6 in magic_file /home/chenpeng/data/FuzzingBench/file/file-git/src/magic.c:397:9     0000011 0x4f3fd5 in process /home/chenpeng/data/FuzzingBench/file/file-git/src/file.c:546:9     0000012 0x4f1c4b in main /home/chenpeng/data/FuzzingBench/file/file-git/src/file.c:416:9     0000013 0x7fc89d20c09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)     0000014 0x41d689 in _start (/mnt/raid/user/chenpeng/FuzzingBench/build/asan/install/bin/file+0x41d689) Address 0x7ffea9a966a0 is located in stack of thread T0 at offset 8384 in frame     #0 0x54779f in dophn_core /home/chenpeng/data/FuzzingBench/file/file-git/src/readelf.c:349   This frame has 3 object(s):     [32, 64) 'ph32'     [96, 152) 'ph64'     [192, 8384) 'nbuf' <== Memory access at offset 8384 overflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext       (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow /scratch/llvm/clang-4/xenial/final/llvm.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors_format.inc:544:9 in printf_common(void*, char const*, __va_li st_tag*) Shadow bytes around the buggy address:   0x10005534ac80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   0x10005534ac90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   0x10005534aca0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   0x10005534acb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   0x10005534acc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x10005534acd0: 00 00 00 00[f3]f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3   0x10005534ace0: f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3   0x10005534acf0: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00   0x10005534ad00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   0x10005534ad10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   0x10005534ad20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes):   Addressable: 00   Partially addressable: 01 02 03 04 05 06 07   Heap left redzone: fa   Freed heap region: fd   Stack left redzone: f1   Stack mid redzone: f2   Stack right redzone: f3   Stack after return: f5   Stack use after scope: f8   Global redzone: f9   Global init order: f6   Poisoned by user: f7   Container overflow: fc   Array cookie: ac   Intra object redzone: bb   ASan internal: fe   Left alloca redzone: ca   Right alloca redzone: cb ==990598==ABORTING
Tags:
Steps To Reproduce:	run: # file sbo1
Additional Information:
Attached Files:	sbo1 (8,714 bytes) 2019-02-18 08:42 https://bugs.astron.com/file_download.php?file_id=40&type=bug

Notes
(0003211) christos    2019-02-18 17:32	Should be fixed in /p/file/cvsroot/file/src/readelf.c,v <-- readelf.c new revision: 1.160; previous revision: 1.159 Thanks!
(0003215) spinpx    2019-02-19 08:11	CVE-2019-8904

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
60	[file] General	minor	have not tried	2019-02-07 06:20	2019-02-18 16:45
Reporter:	silvioprog	Platform:	Linux
Assigned To:	christos	OS:	Ubuntu
Priority:	normal	OS Version:	18.04
Status:	feedback	Product Version:	5.35
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Build fails on mingw-w64 (even installing third party required packages)
Description:	Hello, I've tried to compile the "libmagic" (static only) for Win32 via cross-compile using the MinGW-w64 available on Ubuntu 18.04, but the build fails at configure time, even installing the library "libgnurx" from a unofficial PPA.
Tags:	magic
Steps To Reproduce:	Below the first steps I've tried: $ wget -c ftp://ftp.astron.com/pub/file/file-5.35.tar.gz $ tar -zxvf file-5.35.tar.gz $ cd file-5.35/ $ ./configure --host=i686-w64-mingw32 --enable-static=yes --enable-shared=no [snip] ... checking for ctime_r... no checking for asctime_r... no checking for localtime_r... no checking for gmtime_r... no checking for pread... no checking for strcasestr... no checking for fmtcheck... no checking for dprintf... no checking for gzopen in -lz... no checking for seccomp_init in -lseccomp... no checking for regexec in -lgnurx... no configure: error: libgnurx is required to build file(1) with MinGW
Additional Information:	I've tried to solve the error "libgnurx is required to build file(1) with MinGW" installing the "gnurx" from a third party PPA (since it is not an official distribution, I really would like to not use it), but, just for testing, let's go to install it anyway: sudo add-apt-repository ppa:tobydox/mingw-w64 sudo apt update sudo apt install libgnurx-mingw-w64 Now the "configure" step get finished, but when I try to build the library: make [snip] ... CC file.o CC seccomp.o CCLD file.exe make[3]: Leaving directory '~/file-5.35/src' make[2]: Leaving directory '~/file-5.35/src' Making all in magic make[2]: Entering directory '~/file-5.35/magic' /bin/bash: line 3: file.exe: command not found Cannot use the installed version of file () to cross-compile file 5.35 Please install file 5.35 locally first Makefile:808: recipe for target 'magic.mgc' failed make[2]: *** [magic.mgc] Error 1 make[2]: Leaving directory '~/file-5.35/magic' Makefile:399: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '~/file-5.35' Makefile:331: recipe for target 'all' failed make: *** [all] Error 2
Attached Files:	config.log.tar.gz (15,579 bytes) 2019-02-07 06:23 https://bugs.astron.com/file_download.php?file_id=39&type=bug

Notes
(0003207) silvioprog    2019-02-07 06:23	Full build log in attachment.
(0003208) christos    2019-02-18 16:44	Looks like the file program "file.exe" built correctly and now it is trying to compile the magic file but it cannot execute it. It then tries to execute the installed copy and complains (correctly) because that will not work. Perhaps edit the Makefile and make the command point directly to the locally built file.exe and try again?

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
57	[file] General	minor	always	2018-12-27 10:11	2019-01-18 15:39
Reporter:	alfredwu	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.35
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.36
		Target Version:
Summary:	docx files determined as zip file type.
Description:	/usr/local/file-5.35/bin/file 62b587d18bae01c362c227bf45d7a08d.docx 62b587d18bae01c362c227bf45d7a08d.docx: Zip archive data, at least v1.0 to extract
Tags:
Steps To Reproduce:	/usr/local/file-5.35/bin/file 62b587d18bae01c362c227bf45d7a08d.docx 62b587d18bae01c362c227bf45d7a08d.docx: Zip archive data, at least v1.0 to extract
Additional Information:
Attached Files:	62b587d18bae01c362c227bf45d7a08d.docx (18,871 bytes) 2018-12-27 10:11 https://bugs.astron.com/file_download.php?file_id=37&type=bug

Notes
(0003206) christos    2019-01-18 15:39	Fixed, thanks! /p/file/cvsroot/file/magic/Magdir/msooxml,v <-- msooxml new revision: 1.11; previous revision: 1.10

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
55	[file] General	minor	have not tried	2018-12-17 11:37	2019-01-18 15:26
Reporter:	pombredanne	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	feedback	Product Version:	5.35
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Text file reported as data and application/octet-stream instead of text
Description:	This was originally reported on https://web.archive.org/web/20150815064234/http://bugs.gw.com:80/my_view_page.php as 0000473 but was lost. The attached file is reported as data and application/octet-stream instead of text
Tags:
Steps To Reproduce:	run file and file -i on this file
Additional Information:
Attached Files:	wildtest.txt (4,233 bytes) 2018-12-17 11:37 https://bugs.astron.com/file_download.php?file_id=36&type=bug

Notes
(0003205) christos    2019-01-18 15:26	There are two non-ascii characters in the file: $ diff text55.src.orig text55.src | cat -v 98,99c98,99 < 0000001 1 M-^E [^[:alnum:][:alpha:][:blank:][:cntrl:][:digit:][:graph:][:lower:][:print:][:punct:][:space:][:upper:][:xdigit:]] < 1 1 ^? [^[:alnum:][:alpha:][:blank:][:digit:][:graph:][:lower:][:print:][:punct:][:space:][:upper:][:xdigit:]] --- > 0000001 1 [^[:alnum:][:alpha:][:blank:][:cntrl:][:digit:][:graph:][:lower:][:print:][:punct:][:space:][:upper:][:xdigit:]] > 1 1 [^[:alnum:][:alpha:][:blank:][:digit:][:graph:][:lower:][:print:][:punct:][:space:][:upper:][:xdigit:]]

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
56	[file] General	minor	have not tried	2018-12-17 11:39	2019-01-08 18:24
Reporter:	pombredanne	Platform:
Assigned To:	administrator	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Disallow anonymous user to post on tickets
Description:	This is allowing for a lot of comment spam otherwise. See https://bugs.astron.com/view.php?id=3
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0003204) administrator    2019-01-08 18:24	changed to Viewer.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
37	[tcsh] General	crash	always	2018-09-05 21:02	2018-12-16 18:46
Reporter:	anonymous	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	6.21.00
		Target Version:
Summary:	Pasting a unicode long-hyphen at the prompt crashes TCSH 6.19.01 + with LC_ALL=C
Description:	If I do not set $LC_ALL, I can paste a long-hyphen character '–' into the prompt and it displays properly. If I instead set: setenv LC_ALL C Then try to paste the code, I get a segfault at ed.inputl.c GetNextCommand() at: cmd = CurrentKeyMap[*ch]; I tracked the issue down to PR/437 commit 4b12ecbf108. Reverting this patch allows the paste to go through (it now displays escape characters instead of the hyphen, but doesn't crash). Building on linux x86-64 tcsh --version: (x86_64-unknown-linux) options wide,nls,dl,al,kan,sm,rh,color,filec
Tags:
Steps To Reproduce:	./configure make ./tcsh -f setenv LC_ALL C <paste –>
Additional Information:
Attached Files:

Notes
(0000135) christos    2018-12-16 18:46	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
50	[file] General	minor	always	2018-10-24 14:33	2018-12-16 03:40
Reporter:	red	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.35
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.36
		Target Version:
Summary:	xlsx file is determined as zip
Description:	Hello! xlsx file detected as application/zip.
Tags:	zip
Steps To Reproduce:	file --mime-type ./airports2.xlsx ./airports2.xlsx: application/zip
Additional Information:
Attached Files:	airports2.xlsx (6,452 bytes) 2018-10-24 14:33 https://bugs.astron.com/file_download.php?file_id=33&type=bug

Notes
(0000100) christos    2018-11-05 18:39	This has been fixed on HEAD.
(0000111) christos    2018-12-10 21:15	Feedback timeout.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
29	[file] General	major	always	2018-08-15 19:18	2018-12-10 21:16
Reporter:	Dave_Anderson	Platform:	Mac
Assigned To:	christos	OS:	MacOS
Priority:	high	OS Version:	10.13.6
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.36
		Target Version:
Summary:	file command does not default to "don't follow symlinks" as claimed in --help
Description:	Normally when I point the file command to a symlink I expect file output to indicate that I did so. Instead file tells me what it knows about the file that the the symlink is pointing to. Note that if I provide -h the behavior is as expected. Unfortunately the default acts as though I passed -L: DAs-MacBook-Pro:~ DA$ file --version file-5.31 DAs-MacBook-Pro:~ DA$ file --help Usage: file [OPTION...] [FILE...] Determine type of FILEs.       --help display this help and exit . . .   -L, --dereference follow symlinks   -h, --no-dereference don't follow symlinks (default)  .  .  .  DAs-MacBook-Pro:~ DA$ file `which python3` /usr/local/bin/python3: Mach-O 64-bit executable x86_64 DAs-MacBook-Pro:~ DA$ file -L `which python3` /usr/local/bin/python3: Mach-O 64-bit executable x86_64 DAs-MacBook-Pro:~ DA$ file -h `which python3` /usr/local/bin/python3: symbolic link to ../Cellar/python/3.7.0/bin/python3 DAs-MacBook-Pro:~ DA$ which python3 /usr/local/bin/python3 DAs-MacBook-Pro:~ DA$ ls -l /usr/local/bin/python3 lrwxr-xr-x 1 DA admin 34 Aug 15 11:38 /usr/local/bin/python3 -> ../Cellar/python/3.7.0/bin/python3 DAs-MacBook-Pro:~ DA$ file /usr/local/bin/python3 /usr/local/bin/python3: Mach-O 64-bit executable x86_64 DAs-MacBook-Pro:~ DA$
Tags:
Steps To Reproduce:	See above. Simply run the following: file <full pathname of symlink> or file <relative pathname of symlink>
Additional Information:
Attached Files:

Notes
(0000059) Dave_Anderson    2018-08-15 19:20	Unsure of this project's pri/sev definitions; please correct as needed.
(0000067) christos    2018-08-20 16:07	Unfortunately I fix vendor-provided versions... MacOS/X: [11:58am] 3248>file -v file-5.31 magic file from /usr/share/file/magic [11:58am] 3249>ln -s /dev/null fol [11:58am] 3250>file fol fol: character special (3/2) [11:58am] 3251>uname -a Darwin vpn1-1.astron.com 17.7.0 Darwin Kernel Version 17.7.0: Thu Jun 21 22:53:14 PDT 2018; root:xnu-4570.71.2~1/RELEASE_X86_64 x86_64 [11:58am] 3252> NetBSD [11:59am] 222>file -v file-5.30 magic file from /usr/share/misc/magic [11:59am] 223>ln -s /dev/null fol [12:01pm] 224>file fol fol: symbolic link to /dev/null [12:02pm] 236>./file -v file-5.34 magic file from /usr/local/share/misc/magic [12:02pm] 237>./file ~/fol /u/christos/fol: symbolic link to /dev/null [12:02pm] 225>uname -a NetBSD rebar.astron.com 7.99.59 NetBSD 7.99.59 (GENERIC) amd64
(0000068) Dave_Anderson    2018-08-20 18:26	Not sure what that means. What does vendor-provided mean? if file was provided by Apple(a vendor?) why would it be unfortunate that you will fix it?
(0000069) christos    2018-08-23 09:45	The version I supply works as advertised. The version Apple supplies works differently as we've found out. I don't know why Apple changed it. I don't control what Apple distributes (the note about should read I *cannot* fix vendor supplied versions).
(0000070) Dave_Anderson    2018-08-23 18:25	Thanks. Workaround implemented as follows: DAs-MacBook-Pro:~ DA$ cat ~/.bash_profile ... alias file='file -h' ... -L can override as intended: DAs-MacBook-Pro:~ DA$ file `which python3` /usr/local/bin/python3: symbolic link to ../Cellar/python/3.7.0/bin/python3 DAs-MacBook-Pro:~ DA$ file -L `which python3` /usr/local/bin/python3: Mach-O 64-bit executable x86_64
(0000112) christos    2018-12-10 21:16	Requester has work-around.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
24	[file] General	minor	always	2018-08-02 11:17	2018-12-10 21:15
Reporter:	anonymous	Platform:	Linux
Assigned To:	christos	OS:	Debian
Priority:	normal	OS Version:	4.9.82
Status:	resolved	Product Version:	5.34
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.36
		Target Version:
Summary:	Invalid ZIP archive version
Description:	file reports for a ZIP file (SHA-256 hash: d6125587ffe1ca30833eb3c2b2187b4c8c22584a0899e699fde94f44b3c978c8) $ file d6125587ffe1ca30833eb3c2b2187b4c8c22584a0899e699fde94f44b3c978c8 d6125587ffe1ca30833eb3c2b2187b4c8c22584a0899e699fde94f44b3c978c8: Zip archive data, at least v?[0] to extract file version 5.33 has same output, v 5.32 reported: "Zip archive data"
Tags:	zip
Steps To Reproduce:
Additional Information:
Attached Files:	a (153 bytes) 2018-08-03 11:42 https://bugs.astron.com/file_download.php?file_id=13&type=bug

Notes
(0000038) christos    2018-08-03 08:55	Can you provide a sample file with the problem?
(0000041) anonymous    2018-08-03 11:42	This is not the file that I've mentioned above, but output is same. (note that extract-version is set to 0)
(0000045) christos    2018-08-11 11:11	Fixed on HEAD
(0000099) anonymous    2018-10-23 12:29	I've checked the new version 5.35 and the output for this sample is still "Zip archive data, at least v?[0] to extract". Maybe I got it wrong, so I have more specific question: is "v?[0]" desired output? Now, when I think of it version, version 0 is invalid value, so this is how You want to say "version is unknown, hence `v?`, because version in the file header is 0x00. hence `[0]`.
(0000110) christos    2018-12-10 21:15	Yes, I think that's ok (to print v?[%d], version for the unhandled versions.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
35	[file] General	major	always	2018-08-29 13:35	2018-12-10 21:14
Reporter:	anonymous	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.34
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.36
		Target Version:
Summary:	Video files detected as image/x-tga
Description:	Some MPEG-1/2 Video (mpgv) files are detected as image/x-tga instead of video/mpeg.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	arthurDVDNTSCHiQ.vob (1,429,504 bytes) 2018-08-29 13:35 https://bugs.astron.com/file_download.php?file_id=20&type=bug

Notes
(0000083) christos    2018-10-01 19:18	Can't reproduce with HEAD version.
(0000109) christos    2018-12-10 21:14	Feedback timeout.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
28	[file] General	minor	always	2018-08-13 15:52	2018-12-10 21:12
Reporter:	anonymous	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.34
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.36
		Target Version:
Summary:	file reports a dynamically linked library as ELF 32-bit LSB pie executable instead of ELF 32-bit LSB shared object
Description:	file on the submitted file libtest_lib.so.0.8 created by cmake build on GNU/Hurd reports: 5.33-3 and 5.34-{1,2}: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=f7eb0213a2606a5e3b1bc46d369d2fc47db1d8c5, with debug_info, not stripped 5.29-3: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=f7eb0213a2606a5e3b1bc46d369d2fc47db1d8c5, not stripped Due to that one test fails.
Tags:
Steps To Reproduce:	Run the cmake tests. Debian version 3.12.1-1
Additional Information:
Attached Files:	libtest_lib.so.0.8 (5,100 bytes) 2018-08-13 15:52 https://bugs.astron.com/file_download.php?file_id=19&type=bug

Notes
(0000052) christos    2018-08-14 11:28	Please download and run and unmodified version of file to reproduce. I am not sure where the 5.34.x comes from... ./file -m ../magic/magic.mgc libtest_lib.so.0.8 libtest_lib.so.0.8: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=f7eb0213a2606a5e3b1bc46d369d2fc47db1d8c5, with debug_info, not stripped
(0000053) anonymous    2018-08-14 14:43	file 5.34-2 is from Debian (as all versions mentioned here: https://tracker.debian.org/pkg/file. Upstream releases downloaded from: ftp://ftp.astron.com/pub/file/ There are a number of patches applied though. Dunno yet if they change the output.
(0000054) anonymous    2018-08-14 14:56	After downloading file-5.34.tar.gz and building: LD_LIBRARY_PATH=./src/.libs/libmagic.so.1 src/.libs/file ../libtest_lib.so.0.8 ../libtest_lib.so.0.8: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=dfa3ab0e1cc5aeb84dd5f655ef53977fb87b0aa1, with debug_info, not stripped Same result with: LD_LIBRARY_PATH=./src/.libs/libmagic.so.1 src/.libs/file -m ./magic/magic.mgc ../libtest_lib.so.0.8
(0000055) christos    2018-08-14 15:12	that is really curious now: [11:11am] 125>./file -m ../magic/magic.mgc libtest_lib.so.0.8 libtest_lib.so.0.8: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=f7eb0213a2606a5e3b1bc46d369d2fc47db1d8c5, with debug_info, not stripped [11:11am] 126>uname -a Linux mb1 4.9.0-6-amd64 0000001 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64 GNU/Linux [11:11am] 127>cksum libtest_lib.so.0.8 1407326587 5100 libtest_lib.so.0.8
(0000056) anonymous    2018-08-14 17:09	previous results were reported form a GNU/Hurd box: uname -a GNU hurd-sid 0.9 GNU-Mach 1.8+git20180728-486-dbg/Hurd-0.9 i686-AT386 GNU GNU/Linux-amd64: uname -a Linux z97-4790k 4.9.0-2-amd64 0000001 SMP Debian 4.9.10-1 (2017-02-17) x86_64 GNU/Linux file --version file-5.34 magic file from /etc/magic:/usr/share/misc/magic file ./libtest_lib.so.0.8 ./libtest_lib.so.0.8: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=f7eb0213a2606a5e3b1bc46d369d2fc47db1d8c5, with debug_info, not stripped wget .../ file-5.34.tar.gz uncompresss; configure;make  LD_LIBRARY_PATH=./src/.libs/libmagic.so.1 src/.libs/file ../libtest_lib.so.0.8 ../libtest_lib.so.0.8: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=f7eb0213a2606a5e3b1bc46d369d2fc47db1d8c5, with debug_info, not stripped Same result with: LD_LIBRARY_PATH=./src/.libs/libmagic.so.1 src/.libs/file -m ./magic/magic.mgc ../libtest_lib.so.0.8
(0000057) anonymous    2018-08-14 17:14	cksum ../libtest_lib.so.0.8 1407326587 5100 ../libtest_lib.so.0.8
(0000058) anonymous    2018-08-15 14:19	Hi again. It seems like the difference is that the file generated by cmake for tests is executable on GNU/Hurd but not on GNU/Linux: ls -l ../libtest_lib.so.0.8 -rwxr-xr-x 1 srs srs 7340 Aug 10 13:57 ../libtest_lib.so.0.8 file ../libtest_lib.so.0.8 ../libtest_lib.so.0.8: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=dfa3ab0e1cc5aeb84dd5f655ef53977fb87b0aa1, with debug_info, not stripped chmod -x ../libtest_lib.so.0.8 file ../libtest_lib.so.0.8 ../libtest_lib.so.0.8: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=dfa3ab0e1cc5aeb84dd5f655ef53977fb87b0aa1, with debug_info, not stripped from the rule: magic/Magdir/elf 16 leshort 3 ${x?pie executable:shared object}, The file I uploaded was probably stripped of the +x flag.
(0000060) christos    2018-08-16 06:11	Yes, well while I can remove the code that checks for the shared object being executable, the question is why does hurd installed libraries with the execute bit set :-)
(0000061) anonymous    2018-08-16 08:01	Well, Hurd does not normally install shared libraries with the executable flag on. Only a few ones are executable. I don't know why they are really. However, the library libtest_lib.so.0.8 was created by test code in cmake (Debian version 3.12.1-1)
(0000062) christos    2018-08-16 11:14	Isn't it better to file a bug with Hurd and ask them why some of the libraries are installed executable and others are not, plus fix the CMakefile not to add the execute bit? For example running: $ /lib/x86_64-linux-gnu/libc-2.24.so GNU C Library (Debian GLIBC 2.24-11+deb9u3) stable release version 2.24, by Roland McGrath et al. Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 6.3.0 20170516. Available extensions:         crypt add-on version 2.1 by Michael Glad and others         GNU Libidn by Simon Josefsson         Native POSIX Threads Library by Ulrich Drepper et al         BIND-8.2.3-T5B libc ABIs: UNIQUE IFUNC For bug reporting instructions, please see: <http://www.debian.org/Bugs/>. Is that a PIE binary or a shared object?
(0000064) anonymous    2018-08-16 18:27	Well, some Linux libraries also have the executable flag set: ls -l /lib/x86_64-linux-gnu/libc-2.27.so -rwxr-xr-x 1 root root 1800248 Mar 3 11:47 /lib/x86_64-linux-gnu/libc-2.27.so /lib/x86_64-linux-gnu/libc-2.27.so GNU C Library (Debian GLIBC 2.27-1) stable release version 2.27. Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 7.3.0. libc ABIs: UNIQUE IFUNC For bug reporting instructions, please see: <http://www.debian.org/Bugs/>.
(0000065) christos    2018-08-18 14:33	Yes, the real question is should it? What's the reason or benefit? Should the installation be sloppy about it?
(0000108) christos    2018-12-10 21:12	This is not relevant anymore; the execute bit is not used anymore.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
26	[file] General	minor	always	2018-08-06 16:32	2018-12-10 21:12
Reporter:	anonymous	Platform:	GNU/Linux
Assigned To:	christos	OS:	Kubuntu
Priority:	normal	OS Version:	17.10
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.36
		Target Version:
Summary:	Regex match does not capture all characters to end of line
Description:	I've got an Ansible Vault data file that I'm making magic for; the second and subsequent lines of the example file should be irrelevant (for magic purposes), but I added placeholder lines (to match my actual file) for grins. On the fourth line of my magic config file (the one that starts with ">>&1 regex/1l") my understanding is that "regex/1l" means that I'm specifying a regular expression, and that regex will be searched for in the block starting at the character following the previous match and ending at the end of the line. (It's this last bit, "...and ending at the end of the line", that I suspect is where my understanding is incomplete.) HOWEVER, for some reason the last character of the line is getting chopped off; as you can see in the reproduction, file is only printing "AES25" in the output, rather than "AES256". This agrees with my testing, where if I try to match the regex "AES256" it fails, but matching "AES25" works.
Tags:
Steps To Reproduce:	%) file --version file-5.32 magic file from /home/alumin/.magic:/etc/magic:/usr/share/misc/magic %) cat file-testfile $ANSIBLE_VAULT;1.1;AES256 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000 %) cat dot-magic-notworking ## Ansible Vault files 0 string $ANSIBLE_VAULT Ansible Vault data >&1 regex/1l ([0-9]+(\.[0-9]+)+) \b, version %s >>&1 regex/1l .* \b, using %s encryption !:mime application/ansible-vault !:strength +60 %) cat dot-magic-working ## The only difference is changing "1l" to "2l" on line 4 ## Ansible Vault files 0 string $ANSIBLE_VAULT Ansible Vault data >&1 regex/1l ([0-9]+(\.[0-9]+)+) \b, version %s >>&1 regex/2l .* \b, using %s encryption !:mime application/ansible-vault !:strength +60 %) file --magic-file dot-magic-notworking testfile testfile: Ansible Vault data, version 1.1, using AES25 encryption %) file --magic-file dot-magic-working testfile testfile: Ansible Vault data, version 1.1, using AES256 encryption
Additional Information:	This testing is against version 5.32; apologies for not using the latest version, but it's what I have on my system and I'm kind of expecting this to be a problem with my magic file rather than a bug anyway, so I thought I might skip getting the latest version built and running unless it's necessary. I've attached the three files in question; there's nothing special about them as far as I know, but I suppose you can't be too careful. :)
Attached Files:	dot-magic-notworking (234 bytes) 2018-08-06 16:32 https://bugs.astron.com/file_download.php?file_id=15&type=bug dot-magic-working (234 bytes) 2018-08-06 16:32 https://bugs.astron.com/file_download.php?file_id=16&type=bug file-testfile (1,845 bytes) 2018-08-06 16:32 https://bugs.astron.com/file_download.php?file_id=17&type=bug

Notes
(0000048) christos    2018-08-11 12:13	Fixed on HEAD.
(0000051) anonymous    2018-08-13 21:45	Cool, I assume you mean https://github.com/file/file/commit/b186b4a4ad8b4e6927bb7fd578db572d44bd0712 ? Thanks for looking into it!
(0000107) christos    2018-12-10 21:12	Verified fixed.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
54	[file] General	minor	always	2018-11-25 11:46	2018-12-10 21:09
Reporter:	anonymous	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.33
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.36
		Target Version:
Summary:	Berkeley DB file detection error
Description:	While trying file on a Berkeley DB file (detected as 'Berkeley DB (Btree, version 9, native byte-order)' with file 5.32), I get this result with file 5.33: ', created: Thu Jan 1 00:38:24 1970'. This issue seems to be solved in file-5.34, but my distro uses 5.33.
Tags:
Steps To Reproduce:	run `file` on the attached file.
Additional Information:	I found this issue while compiling diffoscope with python-file instead of python-magic. One of the tests (where I found the attached file) fails because the file is not recognised correctly. For now, I've simply disabled the test to be able to build that tool, but it's not ideal. GuixSD (my distro) cannot update file to a newer version before at least a few months because it requires rebuilding the whole set of packages. However, we can apply patches to the 5.33 version to fix this issue. If there is any patch you can point us to, we can still apply it without having to rebuild everything. Thank you!
Attached Files:	test1.db (32,768 bytes) 2018-11-25 11:46 https://bugs.astron.com/file_download.php?file_id=35&type=bug

Notes
(0000102) anonymous    2018-12-10 00:26	https://cbdoilamericano.com/# where to buy cbd cream for pain https://cbdoilamericano.com/# https://cbdoilamericano.com/#
(0000106) christos    2018-12-10 21:09	You can always compile a newer version of file; even if I fix 5.33, it is uncertain if your upstream will pick up the changes. Thanks for the report anyway.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
53	[file] General	minor	sometimes	2018-11-24 07:39	2018-12-10 21:07
Reporter:	anonymous	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.35
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.36
		Target Version:
Summary:	Output is not always consistent with cso files
Description:	When using the compression tool maxcso to compress PS2 iso files to cso files file(1) does not always recognize them as "Compressed ISO CD image" files and will sometimes recognize them as "data" instead. The files work fine in the PS2 emulator PCSX2 and when decompressed with maxcso they will match the original md5sum of the source iso. $ file Atelier\ Iris\ *.cso Atelier Iris - Eternal Mana [NTSC-U].cso: Compressed ISO CD image Atelier Iris 2: Azoth of Destiny [NTSC-U].cso: data Atelier Iris 3: Grand Phantasm [NTSC-U].cso: Compressed ISO CD image $ file Atelier\ Iris\ *.iso Atelier Iris - Eternal Mana [NTSC-U].iso: UDF filesystem data (version 1.5) '' Atelier Iris 2: Azoth of Destiny [NTSC-U].iso: UDF filesystem data (version 1.5) '' Atelier Iris 3: Grand Phantasm [NTSC-U].iso: UDF filesystem data (version 1.5) 'ATELIER_IRIS_GF' I asked the maxcso developer about this issue his response can be seen in this github issue, in short the assumptions file(1) is making about cso files is not always correct. https://github.com/unknownbrackets/maxcso/issues/26 Unfortunately due to legal reasons I can not provide example files.
Tags:
Steps To Reproduce:	This can be reproduced by compressing various PS2 iso files with maxcso. https://github.com/unknownbrackets/maxcso/
Additional Information:
Attached Files:

Notes
(0000105) christos    2018-12-10 21:07	Added the popular 0x4000 blocksize.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
51	[file] General	minor	always	2018-11-12 00:41	2018-12-10 20:59
Reporter:	anonymous	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.35
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.36
		Target Version:
Summary:	Update MIME types for fonts
Description:	file returns the deprecated application/vnd.ms-opentype and application/font-sfnt as MIME types for otf and ttf fonts, respectively. They should really be font/otf and font/ttf as seen in this table: https://www.iana.org/assignments/media-types/media-types.xhtml#table-font
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000103) christos    2018-12-10 20:59	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
49	[file] General	minor	always	2018-10-18 14:33	2018-10-19 01:04
Reporter:	giosh94mhz	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.34
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.36
		Target Version:
Summary:	Normal TSV identified as Algol 68
Description:	Rules for Algol68 are too broad, and gives some false results, especially with Tab separated text file. Since Algol is pretty rare and TSV very common, this can be a boring issue. For now, I've attached a patch to use exact regex match and limited to only 1024 bytes. A proper/better solution is to do multiple checks for a rare file type like this, but I'm not an Algol developer so I'm a bit clueless here. I think we should use a multiple match, which ensure that 2-3 algol instruction are in place (e.g PROC && MODE && REF, instead of PROC || MODE || REF).
Tags:
Steps To Reproduce:	See sample.xls (actually TSV) attached, and a first non optimal solution in file-algol.patch
Additional Information:
Attached Files:	sample.xls (62 bytes) 2018-10-18 14:33 https://bugs.astron.com/file_download.php?file_id=32&type=bug file-algol.patch (1,069 bytes) 2018-10-18 14:33 https://bugs.astron.com/file_download.php?file_id=31&type=bug

Notes
(0000098) christos    2018-10-19 01:04	applied, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
47	[file] General	trivial	always	2018-10-09 17:50	2018-10-09 21:44
Reporter:	roramirez	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.34
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.35
		Target Version:
Summary:	[PATCH] Add mime and extension for AMR
Description:	Add ext and mime for Adaptive Multi-Rate Codec
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	855500e8ca155116bf7fdbe97c73d682b973b87c.patch (765 bytes) 2018-10-09 17:50 https://bugs.astron.com/file_download.php?file_id=29&type=bug

Notes
(0000095) christos    2018-10-09 21:44	committed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
23	[file] General	minor	have not tried	2018-07-30 15:38	2018-10-08 18:26
Reporter:	vitalyisaev2	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.34
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.35
		Target Version:
Summary:	JSON is determined as "text/plain"
Description:	Hello! I think that JSON files should have "application/json" content-type according to RFC4627 (http://www.ietf.org/rfc/rfc4627.txt) Kind regards, Vitaly
Tags:
Steps To Reproduce:	[root@9826ba54a40a /]# cat /tmp/ololo.json {     "abc": "edf",     "json": "crab",     "ololo": [         1,         2,         3     ],     "subcrab": {         "name": "crab",         "surname": "subcrab"     } } [root@9826ba54a40a /]# file --version file-5.34 magic file from /etc/magic:/usr/share/misc/magic [root@9826ba54a40a /]# file --mime-type /tmp/ololo.json /tmp/ololo.json: text/plain
Additional Information:
Attached Files:	ololo.json (144 bytes) 2018-07-30 15:38 https://bugs.astron.com/file_download.php?file_id=12&type=bug

Notes
(0000040) christos    2018-08-03 09:15	Yes, but that would require something in file to be able to parse json (so that it can determine if it is json)... What about a json file that has a syntax error? Should it be recognized as json?
(0000042) anonymous    2018-08-08 06:55	Hi! I suppose that we should recognize it as json in all cases when it's possible. Even it has a syntax error. Of course this behaviour depends on json parser.
(0000043) vitalyisaev2    2018-08-08 07:43	Perhaps libmagic could use some lightweight library that will just validate JSON (without building whole deserialized object in memory)... I'm not sure if we are able to distinguish JSON with syntax error and arbitrary text file. From my point of view, falling back to "text/plain" with broken JSON would be a better option.
(0000044) christos    2018-08-11 11:06	Fixed on HEAD.
(0000050) vitalyisaev2    2018-08-13 10:51	Thank you, going to check it in a couple of days
(0000092) vitalyisaev2    2018-10-08 14:24	Sorry for the delay with response, I've checked it, works good. I think we can close this issue.
(0000094) christos    2018-10-08 18:26	Submitter verified it is fixed.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
46	[file] General	minor	have not tried	2018-10-08 14:12	2018-10-08 18:26
Reporter:	vitalyisaev2	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.34
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.35
		Target Version:
Summary:	docx file is determined as zip
Description:	Hello, please consider this docx file which is determined as zip. It's valid and can be opened by LIbreOffice, but file (compiled from repository's HEAD) does not agree that it's docx file. Thank you.
Tags:
Steps To Reproduce:	file --mime-type /tmp/office.docx /tmp/office.docx: application/zip
Additional Information:
Attached Files:	office.docx (34,220 bytes) 2018-10-08 14:12 https://bugs.astron.com/file_download.php?file_id=28&type=bug

Notes
(0000093) christos    2018-10-08 18:26	Made the zip search deeper; thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
32	[file] General	minor	have not tried	2018-08-24 23:09	2018-10-02 01:11
Reporter:	Chai T. Rex	Platform:	x86-64, Kaby Lake
Assigned To:	christos	OS:	Ubuntu
Priority:	normal	OS Version:	16.04.5
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	file declares that Bash process substitution uses a broken symlink
Description:	Apologies if this has already been fixed. In Ubuntu 16.04.5, with file-5.25, Bash process substitution fails, claiming that there's a broken symbolic link to a pipe. The same sort of symbolic link works just fine with other programs, so there's something wrong with file's detection of broken symlinks.
Tags:
Steps To Reproduce:	1. Note that Bash process substitution works in general, so the symlink that's involved must be properly readable:     $ /bin/cat <( echo '#!/bin/sh' )     #!/bin/sh 2. Note that file gives an error:     $ /usr/bin/file <( echo '#!/bin/sh' )     /dev/fd/63: broken symbolic link to pipe:[10713867]
Additional Information:	The version of the Ubuntu APT package called file is 1:5.25-2ubuntu1.1.     $ /usr/bin/file --version     file-5.25     magic file from /etc/magic:/usr/share/misc/magic
Attached Files:

Notes
(0000085) christos    2018-10-01 19:24	$ ls -l <(echo "foo bar") lr-x------ 1 christos users 64 Oct 1 15:22 /dev/fd/63 -> pipe:[3511315244] So what happens if you readlink(2) /dev/fd/63 and then try to open the result instead of opening it directly? What's supposed to happen?
(0000087) christos    2018-10-01 20:00    (Last edited: 2018-10-01 20:01)	This is only broken on Linux; other systems with a proper procfs/devfs implementation work just fine :-)
(0000091) christos    2018-10-02 01:11	Should be fixed now.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
45	[file] General	minor	always	2018-09-17 07:54	2018-10-01 23:34
Reporter:	sezero	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.34
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.35
		Target Version:
Summary:	unreadable output for macho fat files
Description:	$ file --version file-5.34 magic file from /home/sezero/opt/file-5.34/share/misc/magic $ file wildmidi wildmidi: Mach-O universal binary with 3 architectures: [x86_64:Mach-O 64-bit x86_64 executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL>] [ppc:Mach-O ppc executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL>] This is a fat file with x86_64, i386 and ppc architectures. While trying to output flags (useless IMHO, but it's just me), file loses one of the arches (i386) and the output is pretty much unreadable. As far as I can tell, this behavior began with file-5.27 (file-5.26 doesn't compile for me.) With file-5.25, the output was readable, although it did lose the last arch, i.e. ppc: wildmidi: Mach-O universal binary with 3 architectures: [x86_64: Mach-O 64-bit x86_64 executable] [i386: Mach-O i386 executable] []
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	wildmidi (73,772 bytes) 2018-10-01 19:22 https://bugs.astron.com/file_download.php?file_id=27&type=bug

Notes
(0000078) christos    2018-10-01 19:02	Do you have a binary that reproduces this? I get: ./file -m ../magic/magic.mgc /bin/sync /bin/sync: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit x86_64 executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE>] [i386:Mach-O i386 executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE|NO_HEAP_EXECUTION>]
(0000079) christos    2018-10-01 19:03	waiting for example.
(0000084) sezero    2018-10-01 19:22	The tarball here has the file I referred to in the original report: https://github.com/Mindwerks/wildmidi/releases/download/wildmidi-0.3.14/wildmidi-0.3.14-macosx.tar.gz Also attaching one of the files from that tarball here.
(0000088) christos    2018-10-01 20:43	Hmm, something is fishy with that file: Apple's file binary finds 3 architectures, but only in the body, not in the headers: $ file wildmidi wildmidi: Mach-O universal binary with 3 architectures: [x86_64:Mach-O 64-bit executable x86_64] [ppc:Mach-O executable ppc] wildmidi (for architecture x86_64): Mach-O 64-bit executable x86_64 wildmidi (for architecture i386): Mach-O executable i386 wildmidi (for architecture ppc): Mach-O executable ppc Will look into it some more.
(0000089) sezero    2018-10-01 21:11	lipo (from cctools-port) three arches in header: $ /opt/cctools-port/bin/i686-apple-darwin9-lipo -detailed_info wildmidi Fat header in: wildmidi fat_magic 0xcafebabe nfat_arch 3 architecture x86_64     cputype CPU_TYPE_X86_64     cpusubtype CPU_SUBTYPE_X86_64_ALL     offset 4096     size 19832     align 2^12 (4096) architecture i386     cputype CPU_TYPE_I386     cpusubtype CPU_SUBTYPE_I386_ALL     offset 24576     size 23976     align 2^12 (4096) architecture ppc     cputype CPU_TYPE_POWERPC     cpusubtype CPU_SUBTYPE_POWERPC_ALL     offset 49152     size 24620     align 2^12 (4096)
(0000090) christos    2018-10-01 23:34	Fixed to print the missing arch, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
31	[file] General	text	always	2018-08-23 17:05	2018-10-01 20:00
Reporter:	anonymous	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.34
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.35
		Target Version:
Summary:	pstring documentation error
Description:	The documentation states that:                           B A byte length (default).                           H A 4 byte big endian length.                           h A 2 byte big endian length.                           L A 4 byte little endian length.                           l A 2 byte little endian length. Looking at the source that is not correct. It should have been:                           B A byte length (default).                           H A 2 byte big endian length.                           h A 2 byte little endian length.                           L A 4 byte big endian length.                           l A 4 byte little endian length.
Tags:
Steps To Reproduce:
Additional Information:	Look in the source-code after CHAR_PSTRING_2_BE CHAR_PSTRING_2_LE CHAR_PSTRING_4_BE CHAR_PSTRING_4_LE
Attached Files:

Notes
(0000086) christos    2018-10-01 20:00	thanks

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
38	[file] General	trivial	always	2018-09-10 11:56	2018-10-01 19:14
Reporter:	bbc	Platform:
Assigned To:	christos	OS:
Priority:	low	OS Version:
Status:	resolved	Product Version:	5.34
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.35
		Target Version:
Summary:	Typo in text for Microsoft Roslyn
Description:	Attached is a patch. I didn't know where to send it so here it is.
Tags:
Steps To Reproduce:	Run: file foo.pdb
Additional Information:
Attached Files:	fix_typo_roslyn.patch (604 bytes) 2018-09-10 11:56 https://bugs.astron.com/file_download.php?file_id=22&type=bug

Notes
(0000082) christos    2018-10-01 19:14	thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
36	[file] General	minor	have not tried	2018-09-05 19:13	2018-10-01 19:12
Reporter:	cbiedl	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.34
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.35
		Target Version:
Summary:	Remaining references to gw.com
Description:	Seems there are some references left to the defunct gw.com domain. Please fix `magic/Header` and `src/file.c` while `magic/Magdir/wsdl` probably cannot be cured.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000081) christos    2018-10-01 19:12	fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
40	[file] General	minor	always	2018-09-15 15:46	2018-10-01 19:11
Reporter:	anonymous	Platform:	x86_64 GNU/Linux
Assigned To:	christos	OS:	Arch Linux
Priority:	normal	OS Version:	4.16.13-1
Status:	resolved	Product Version:	5.34
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.35
		Target Version:
Summary:	Wrong mime type of Canon CR2 raw image data
Description:	The mime type of Canon CR2 raw image data is recognized as image/tiff. In version 5.33 and older versions the mime type of Canon CR2 raw image data was determined correctly as image/x-canon-cr2.
Tags:
Steps To Reproduce:	file --mime-type -b image.cr2
Additional Information:	Example files can be downloaded from the pixls.us website. E.g.: http://raw.pixls.us/data/Canon/EOS%207D/RAW_CANON_EOS_7D-raw.CR2
Attached Files:

Notes
(0000080) christos    2018-10-01 19:11	bump strength to beat tiff.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
39	[file] General	trivial	always	2018-09-13 16:08	2018-10-01 18:58
Reporter:	jidanni	Platform:	Debian
Assigned To:	christos	OS:
Priority:	low	OS Version:
Status:	resolved	Product Version:	5.34
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.35
		Target Version:
Summary:	Document jpeg "frames 3"
Description:	Document on the man page if "frames 3" is talking about some kind of layer. https://photo.stackexchange.com/questions/9606/do-jpgs-have-layers
Tags:
Steps To Reproduce:	$ file ...jpg ... 1836x3264, frames 3
Additional Information:	$ identify -verbose ...jpg doesn't mention any frames.
Attached Files:

Notes
(0000077) christos    2018-10-01 18:58	changed "frames" to "components"

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
34	[file] General	feature	always	2018-08-29 11:35	2018-10-01 18:53
Reporter:	anonymous	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.33
Product Build:		Resolution:	no change required
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	allow piping
Description:	so i was wondering what kind of files live in my /usr/lib directory, so i naively tried: find /usr/lib -type f | file but only got the `file` usage info printed out. so i assume we cannot pipe filepaths to `file`? could we have this awesome feature?
Tags:
Steps To Reproduce:	find /usr/lib -type f | file
Additional Information:
Attached Files:

Notes
(0000076) christos    2018-10-01 18:53	find . -type f | file -f -

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
33	[file] General	minor	have not tried	2018-08-24 23:32	2018-10-01 18:51
Reporter:	Chai T. Rex	Platform:	x86-64, Kaby Lake
Assigned To:	christos	OS:	Ubuntu
Priority:	normal	OS Version:	16.04.5
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.35
		Target Version:
Summary:	file --help bug reporting location is outdated
Description:	According to the definition of `help()` in the GitHub repo file/file's `file.c` source code (with relevant lines highlighted at https://github.com/file/file/blob/master/src/file.c#L643-L661), the location to report bugs given by `file --help` is:     Report bugs to http://bugs.gw.com/ That domain is dead and should be updated to the current man page's URL (with relevant lines highlighted at https://github.com/file/file/blob/master/doc/file.man#L631-L638):     Please report bugs and send patches to the bug tracker at     .Pa http://bugs.astron.com/     or the mailing list at     .Aq file@astron.com     (visit     .Pa http://mailman.astron.com/mailman/listinfo/file     first to subscribe).
Tags:
Steps To Reproduce:	1. View the source code. 2. Notice that `file --help` will produce the wrong bug-reporting URL.
Additional Information:	It may also be good to change the URLs in both the `man` page and `file --help` output to HTTPS instead of HTTP as a simple way to avoid a few security troubles.
Attached Files:

Notes
(0000075) christos    2018-10-01 18:51	thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
43	[file] General	minor	have not tried	2018-09-16 07:29	2018-10-01 18:49
Reporter:	petk	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.34
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.35
		Target Version:
Summary:	Obsolete HAVE_STDDEF_H symbol
Description:	The <stddef.h> header file is part of the standard C89 headers [1] and on current systems can be included unconditionally. Since file requires at least C89 or greater, the HAVE_STDDEF_H symbol defined by Autoconf in configure.ac [2] can be ommitted and simplifed. Refs: [1] https://port70.net/~nsz/c/c89/c89-draft.html#4.1.2 [2] https://git.savannah.gnu.org/cgit/autoconf.git/tree/lib/autoconf/headers.m4 Thank you.
Tags:
Steps To Reproduce:
Additional Information:	Pull request has been opened also at https://github.com/file/file/pull/41 for better overview.
Attached Files:	41.patch (2,120 bytes) 2018-09-16 07:29 https://bugs.astron.com/file_download.php?file_id=25&type=bug

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
41	[file] General	minor	always	2018-09-16 07:00	2018-10-01 18:49
Reporter:	petk	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.34
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.35
		Target Version:
Summary:	Obsolete HAVE_LIMITS_H symbol
Description:	The <limits.h> header file is part of the standard C89 headers [1] and on current systems there is no need to manually check if header is present anymore. Since the code requires at least C89 or greater, the HAVE_LIMITS_H symbol defined by Autoconf in configure.ac [2] can be removed and simplifed. Refs: [1] https://port70.net/~nsz/c/c89/c89-draft.html#4.1.2 [2] https://git.savannah.gnu.org/cgit/autoconf.git/tree/lib/autoconf/headers.m4
Tags:
Steps To Reproduce:
Additional Information:	Pull request for additional info and overview of this is at https://github.com/file/file/pull/39
Attached Files:	39.patch (3,246 bytes) 2018-09-16 07:00 https://bugs.astron.com/file_download.php?file_id=23&type=bug

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
44	[file] General	minor	have not tried	2018-09-17 00:26	2018-10-01 18:48
Reporter:	anonymous	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.34
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.35
		Target Version:
Summary:	Obsolete HAVE_SIGNAL_H symbol
Description:	The <signal.h> header file is part of the standard C89 headers [1] and on current systems can be included unconditionally. Since file requires at least C89 or greater, the HAVE_SIGNAL_H symbol defined by Autoconf in configure.ac [2] can be ommitted and simplifed. Refs: [1] https://port70.net/~nsz/c/c89/c89-draft.html#4.1.2 [2] https://git.savannah.gnu.org/cgit/autoconf.git/tree/lib/autoconf/headers.m4 Thank you.
Tags:
Steps To Reproduce:
Additional Information:	Pull request has been also opened on GitHub for better overview of the patch needed. https://github.com/file/file/pull/42
Attached Files:	42.patch (2,813 bytes) 2018-09-17 00:26 https://bugs.astron.com/file_download.php?file_id=26&type=bug

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
42	[file] General	minor	always	2018-09-16 07:06	2018-10-01 18:48
Reporter:	petk	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.34
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.35
		Target Version:
Summary:	Obsolete HAVE_LOCALE_H symbol
Description:	The <locale.h> header file is part of the standard C89 headers [1] and on current systems can be included unconditionally. Since file requires at least C89 or greater, the HAVE_LOCALE_H symbol defined by Autoconf in configure.ac [2] can be ommitted and simplifed. Refs: [1] https://port70.net/~nsz/c/c89/c89-draft.html#4.1.2 [2] https://git.savannah.gnu.org/cgit/autoconf.git/tree/lib/autoconf/headers.m4 Thank you.
Tags:
Steps To Reproduce:
Additional Information:	Pull request for additional info is at https://github.com/file/file/pull/40
Attached Files:	40.patch (1,645 bytes) 2018-09-16 07:06 https://bugs.astron.com/file_download.php?file_id=24&type=bug

Notes
(0000073) christos    2018-09-17 00:37	Have you tried building with visual studio (is it c89?)?
(0000074) petk    2018-09-17 01:32	Hello, I haven't build this with Visual Studio but I can check it out via some virtual machine how this works... Visual Studio 2015 and 2017 should both support C89 standard headers, yes. For example: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/setlocale-wsetlocale?view=vs-2015

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
30	[file] General	minor	always	2018-08-16 18:47	2018-08-20 15:52
Reporter:	cbiedl	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	5.34
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.35
		Target Version:
Summary:	Different behaviour for setparam with value zero
Description:	Hi there, the file program ignores any parameter set using --parameter if the value is zero (file.c:430). At the same time, an according magic_setparam call does set the value. It might be questionable whether the value zero should be supported - in my opinion it should, even if just for tests and weird experiments. However, I'd appreciate if the file program and libmagic would show the same behaviour. The current situation created some confusion when trying to test effects of --parameter before using the function in an application. Regards,
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000066) christos    2018-08-20 15:52	fixed

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
25	[file] General	minor	have not tried	2018-08-06 06:19	2018-08-11 12:18
Reporter:	cbiedl	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.35
		Target Version:
Summary:	Magic strength computation underflow
Description:	This doesn't look good:     $ file --list | grep FORTRAN     Strength = 18446744073709551613@7: FORTRAN program text [text/x-fortran] The problem is in `apprentice_magic_strength`: The `val` variable is size_t but as result of substraction the computation might underflow. The obvious approach was to guard `val` before such an operation but it turns out some rule start with `!:strength - 1` and the like, so that change would cause other and surprising damage. Suggestion: Make `val` a signed long which should be big enough to avoid overflow. If the resulting value is still negative, set it to one. Also move that operation a block down to a place where it seems more appropriate. This yields (as the only change)     $ file --list | grep FORTRAN     Strength = 2@7: FORTRAN program text [text/x-fortran] which looks much better. As a side effect, the strength of     @42: Perl5 module source text went down by one, so adjust this to maintain the current status which is the result of delicate tuning IIRC.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	strength-underflow.patch (1,546 bytes) 2018-08-06 06:19 https://bugs.astron.com/file_download.php?file_id=14&type=bug

Notes
(0000049) christos    2018-08-11 12:18	Applied, but with long -> ssize_t

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
27	[file] General	minor	have not tried	2018-08-06 19:37	2018-08-11 11:32
Reporter:	cbiedl	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.35
		Target Version:
Summary:	Fix HPROF detection
Description:	Seems it wasn't my brightest day when I submitted "Java HPROF dumps" a few years ago. So: "short" should have been "byte", this breaks detection on big endian. And the creation stamp should be printed only if the previous line matched. Patch below. Besides, the URL is 404.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	hprof.patch (657 bytes) 2018-08-06 19:37 https://bugs.astron.com/file_download.php?file_id=18&type=bug

Notes
(0000047) christos    2018-08-11 11:32	Applied, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
22	[file] General	minor	have not tried	2018-07-26 20:57	2018-08-06 21:22
Reporter:	cbiedl	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.35
		Target Version:
Summary:	Possible typo in magic.man: warning: macro `It' not defined
Description:	Hello, commit cc32246d2aa7cc6ecc2071d1d6ea3c6a7015f2f2 Author: Christos Zoulas <christos@zoulas.com> Date: Fri Jun 22 20:39:49 2018 +0000     Add quad indirect offsets added ".It S2" to the first line of doc/magic.man, which triggers a warning by man about an undefined macro. Care to check?
Tags:	compression
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000031) christos    2018-08-01 10:31	fixed, thanks

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
12	[file] General	feature	have not tried	2018-07-22 10:03	2018-08-02 06:33
Reporter:	cbiedl	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.35
		Target Version:
Summary:	Please support EDID (Extended Display Identification Data)
Description:	See https://bugs.debian.org/896932 File format description is at https://en.wikipedia.org/wiki/Extended_Display_Identification_Data Tentative magic:     0 string \x00\xFF\xFF\xFF\xFF\xFF\xFF\x00     >19 byte x     >>18 byte x EDID data, version %u.     >>19 byte x \b%u Also, I'd like to add     >>17 ubyte+1990 <255 \b, manufactured %u but there's an overrun so a value 22 is shown as 220, not 2012
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000037) christos    2018-08-02 06:33	Applied, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
10	[file] General	minor	always	2018-07-13 22:07	2018-08-02 06:26
Reporter:	anonymous	Platform:	Debian
Assigned To:	christos	OS:	Linux
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.35
		Target Version:
Summary:	Please tech file to recognize the Sketchup 3D model format
Description:	This is forwarded from <URL: https://bugs.debian.org/903693 >. The Sketchup 3D model format is used by the Sketchup modelling tool available from <URL: https://www.sketchup.com/ >. This is how it is handled at the moment:   % file 35vertical.skp   35vertical.skp: Zip archive data, o   % file --mime 35vertical.skp   35vertical.skp: application/octet-stream; charset=binary   % According to <URL: https://www.filesuffix.com/en/extension/skp >, its MIME type should be application/vnd.sketchup.skp. According to <URL:https://www.iana.org/assignments/media-types/application/vnd.sketchup.skp>, this format is not registered with IANA. An example file can be downloaded from <URL: https://www.thingiverse.com/thing:898198 >.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000011) cbiedl    2018-07-22 07:56	As apparently all sketchup files have an identical header (some framing and a ucs-2 encoded text), the magic is fairly simple: 0 string \xff\xfe\xff\x0e\x53\x00\x6b\x00\x65\x00\x74\x00\x63\x00\x68\x00\x55\x00\x70\x00\x20\x00\x4d\x00\x6f\x00\x64\x00\x65\x00\x6c\x00 SketchUp Model !:mime application/vnd.sketchup.skp !:ext skp The Debian package will ship this from the next version on.     Christoph PS: Any chance we'll ever have the mailing list again?
(0000036) christos    2018-08-02 06:26	Added magic, and the mailing list is in mailman.astron.com

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
14	[file] General	minor	have not tried	2018-07-22 12:50	2018-08-01 13:44
Reporter:	cbiedl	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	feedback	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Issues with flif magic
Description:	Debian bug: https://bugs.debian.org/864023 The current state of flif (Free Lossless Image Format) detection is fairly broken. Things don't getter by looking at the spec¹ as apparently implementation is somewhat different. As far as I can tell from the flif sources and images I've created using the flif tool: The dimension (width, height) information is at offset 6 (spec says: 7). They are certainly not short but "varint", a dynamic format that can hold arbitrary values without wasting space (more or less the way, a length information is stored in ASN.1). And a minor issue: The trailing comma as in "8-bit/color," leads to doubled comma in the output. No idea how to proceed from here. Maybe ask the original submitter for review, assuming they have a bigger collection of flif files? Cheers,     Christoph ¹ http://flif.info/spec.html
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000035) christos    2018-08-01 13:44	Hmm, I wrote code to parse varint, but it seems that all the image examples I have work fine with the non-varint magic...

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
16	[file] General	minor	have not tried	2018-07-24 20:05	2018-08-01 12:05
Reporter:	cbiedl	Platform:	Linux
Assigned To:	christos	OS:	Debian
Priority:	normal	OS Version:	all
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.35
		Target Version:
Summary:	magic for AutoCAD Drawing Exchange Format
Description:	Debian bug https://bugs.debian.org/702744 The original proposal introduced a lot of regressions; I reworked it and found no mis-detection even after checking my huge collection. Still this could take some improvement, especially the regular expression should better be something less expensive. So for the record, the file format is something like: * Format is text, line-based, DOS line endings * The first four lines are     0     SECTION     2     HEADER   where at least the numbers might be indented with whitespace. * Further below there might be a keyword like "AC1006", denoting the   actual version. Also, the \000 in the first pattern is just a dirty hack to avoid the string "ASCII text, with CRLF line terminators" is appended to the output. Which, although technically correct, adds more confusion than help, YMMV. # AutoCAD Drawing Exchange Format 0 regex \^[\ \t]*0\r?\000$ >1 regex \^[\ \t]*SECTION\r?$ >>2 regex \^[\ \t]*2\r?$ >>>3 regex \^[\ \t]*HEADER\r?$ AutoCAD Drawing Exchange Format !:mime application/x-dxf !:ext dxf >>>>&1 search/8192 AC1006 \b, R10 >>>>&1 search/8192 AC1009 \b, R11/R12 >>>>&1 search/8192 AC1012 \b, R13 >>>>&1 search/8192 AC1014 \b, R14 >>>>&1 search/8192 AC1015 \b, version 2000 >>>>&1 search/8192 AC1018 \b, version 2004 >>>>&1 search/8192 AC1021 \b, version 2007 >>>>&1 search/8192 AC1024 \b, version 2010
Tags:
Steps To Reproduce:
Additional Information:
System Description	Maintainer for the file package in Debian.
Attached Files:

Notes
(0000034) christos    2018-08-01 12:05	Applied, thanks

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
19	[file] General	minor	have not tried	2018-07-26 04:56	2018-08-01 10:34
Reporter:	cbiedl	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.35
		Target Version:
Summary:	Recognize ia64 and amd64 COFF files
Description:	Debian bug: https://bugs.debian.org/697846 Please consider the attached path to identify some 64bit architecture COFF files. Regards,     Christoph
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	upstream.coff-amd64.patch (1,022 bytes) 2018-07-26 04:56 https://bugs.astron.com/file_download.php?file_id=10&type=bug

Notes
(0000033) christos    2018-08-01 10:34	Fixed, thanks

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
21	[file] General	minor	have not tried	2018-07-26 20:45	2018-08-01 10:33
Reporter:	cbiedl	Platform:	Linux
Assigned To:	christos	OS:	Debian
Priority:	normal	OS Version:	all
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	5.35
		Target Version:
Summary:	[PATCH] Add png extensions
Description:	Ubuntu bug https://bugs.launchpad.net/ubuntu/+source/file/+bug/1726096 Add extensions for png
Tags:
Steps To Reproduce:
Additional Information:
System Description	Maintainer for the file package in Debian.
Attached Files:	ubuntu-1726096.patch (434 bytes) 2018-07-26 20:45 https://bugs.astron.com/file_download.php?file_id=11&type=bug

Notes
(0000032) christos    2018-08-01 10:33	Fixed, thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4	[file] General	minor	N/A	2018-06-17 19:55	2018-08-01 10:22
Reporter:	valoq	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Several issues reported by coverity
Description:	The static code analysis tool coverity found several issues in file https://scan.coverity.com/projects/linuxsandboxingproject-file Since the tool does not provide a mean to extract the result in a readable form, the details can only be accessed after login I have attached one example issue below
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	oobaccess (1,277 bytes) 2018-06-17 19:55 https://bugs.astron.com/file_download.php?file_id=3&type=bug

Notes
(0000006) christos    2018-06-23 16:15	I don't see the problem with the attached code; I have asked the owners to give me access to see the rest of the coverity issues.
(0000030) christos    2018-08-01 10:22	All coverity issues have been addressed; the one mentioned here is a false-positive.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
6	[file] General	crash	always	2018-06-22 14:55	2018-08-01 09:05
Reporter:	tobias	Platform:	i686
Assigned To:	christos	OS:	Linux
Priority:	normal	OS Version:	4.17.2
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	out of boundary read in DER parser
Description:	It is possible to trigger an out of boundary read in DER parser if a custom magic file is used. Parsing the length of a tag allows UINT32_MAX which will overflow the check if enough memory is available. It is therefore needed to check for an UINT32_MAX overflow before checking the available amount of data.
Tags:
Steps To Reproduce:	$ mkdir ~/magic $ cp der-magic ~/magic $ file -m ~/magic poc.der Segmentation fault (core dumped) $ _
Additional Information:
Attached Files:	file-5.33-der.patch (326 bytes) 2018-06-22 14:55 https://bugs.astron.com/file_download.php?file_id=5&type=bug poc.der (28 bytes) 2018-06-22 14:55 https://bugs.astron.com/file_download.php?file_id=6&type=bug der-magic (30 bytes) 2018-06-22 14:55 https://bugs.astron.com/file_download.php?file_id=7&type=bug

Notes
(0000003) christos    2018-06-23 15:15	Patch applied thanks!
(0000029) christos    2018-08-01 09:05	feedback timeout

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
5	[file] General	minor	always	2018-06-22 14:50	2018-08-01 09:05
Reporter:	tobias	Platform:	i686
Assigned To:	christos	OS:	Linux
Priority:	normal	OS Version:	4.17.2
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	seccomp is lacking 32 bit support
Description:	The allowed system calls are not enough for 32 bit Linux systems with large file support. I have extended the commands to pass installation (make install fails during magic creation) and at least basic usage.
Tags:
Steps To Reproduce:	Run "./configure && make && make install" on a 32 bit Linux system which uses large file support.
Additional Information:
Attached Files:	file-5.33-seccomp.patch (735 bytes) 2018-06-22 14:50 https://bugs.astron.com/file_download.php?file_id=4&type=bug

Notes
(0000004) christos    2018-06-23 16:09	Patch applied, thanks!
(0000028) christos    2018-08-01 09:05	feedback timeout

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
13	[file] General	minor	have not tried	2018-07-22 10:51	2018-08-01 09:04
Reporter:	cbiedl	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	ELF: Please handle files without program headers gracefully
Description:	Debian bug: https://bugs.debian.org/882310 libmagic reports files without a program header as "corrupted program header size". As mentioned in that report, there used to be a fix for this in Redhat¹ some whopping 15 years ago, but it apparently never was upstreamed. I took the liberty to forward-port it to 5.33 ¹ https://bugzilla.redhat.com/attachment.cgi?id=95833&action=diff&context=patch&collapsed=&headers=1&format=raw
Tags:
Steps To Reproduce:	See the Debian bug
Additional Information:
Attached Files:	0001-ELF-Handle-files-without-program-headers-gracefully.patch (1,565 bytes) 2018-07-22 10:51 https://bugs.astron.com/file_download.php?file_id=9&type=bug

Notes
(0000013) christos    2018-07-25 06:12	Applied, thanks!
(0000027) christos    2018-08-01 09:04	feedback timeout

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2	[file] General	minor	always	2018-06-12 09:33	2018-08-01 09:04
Reporter:	Hugal31	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Too much false positive for DIY-Thermocam format
Description:	I think the DIY-Thermocam format in the "measure" magic file is unwell defined and causes too many false positives. For example : # V1 or Lepton 2.x 9608 byte <19 >9600 use diy-thermocam-checker >>9600 default x (Lepton 2.x), >>>9600 use diy-thermocam-parser A file with the byte 3840 set to 0xFF, for example, will trigger the first line, because it will be resolved as signed "-1", and "-1 < 19" is true. I believe this behaviour is incorrect and can be solved by using "ubyte" and "ulefloat". The same applies to the other rules, where I think changing the signed condition to an unsigned would greatly reduce the number of false positives. I don't know the DIY-Thermocam format, and it was added by someone named "Harald Geyer". If someone know the file format or know how to contact him, please help to fix this magic file.
Tags:
Steps To Reproduce:	Use underflow to trigger some rules. See file attached for example.
Additional Information:
Attached Files:	measure-fake.bin (9,621 bytes) 2018-06-12 09:33 https://bugs.astron.com/file_download.php?file_id=2&type=bug

Notes
(0000005) christos    2018-06-23 16:13	Fixed as suggested
(0000026) christos    2018-08-01 09:04	feedback timeout

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
7	[file] General	minor	always	2018-06-22 21:54	2018-08-01 09:03
Reporter:	bodo	Platform:
Assigned To:	christos	OS:
Priority:	low	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	python function magic.detect_from_filename does not handle non-existent file
Description:	The python api provides the function magic.detect_from_filename. When the file given as argument does not exist, it throws the exception ValueError: not enough values to unpack (expected 2, got 1) which does not correctly represent the failure condition. detect_from_filename calls _create_filemagic with the return value of mime_magic.file. If the file does not exist, mime_magic.file returns "cannot open `foobar' (No such file or directory)". _create_filemagic then goes on to split that value into mime_type and mime_encoding. But as the error message does not contain a semicolon, this leads to the above exception.
Tags:
Steps To Reproduce:	Do not have the file 'foobar' in the current directory and execute the following in the python intepreter: >>> import magic >>> magic.detect_from_filename('foobar') Traceback (most recent call last):   File "<stdin>", line 1, in <module>   File "/usr/lib64/python3.5/site-packages/magic.py", line 264, in detect_from_filename     none_magic.file(filename))   File "/usr/lib64/python3.5/site-packages/magic.py", line 251, in _create_filemagic     mime_type, mime_encoding = mime_detected.split('; ') ValueError: not enough values to unpack (expected 2, got 1)
Additional Information:	versions: - sys-apps/file-5.32 on gentoo linux with USE="+python" - python-3.5.5
Attached Files:

Notes
(0000002) christos    2018-06-23 14:58	Committed a change to raise the actual error as a ValueError
(0000008) bodo    2018-06-24 14:11	Works fine in python2 now. Python3 gives: TabError: inconsistent use of tabs and spaces in indentation Please replace your tabs with 8 spaces.
(0000009) christos    2018-06-24 15:51	Fixed, thanks!
(0000012) christos    2018-07-25 06:08	Should be fixed in HEAD: $ python Python 2.7.13 (default, Feb 13 2017, 09:50:26) [GCC 5.4.0] on netbsd7 Type "help", "copyright", "credits" or "license" for more information. >>> import magic >>> magic.detect_from_filename('foobar') Traceback (most recent call last):   File "<stdin>", line 1, in <module>   File "magic.py", line 267, in detect_from_filename     none_magic.file(filename))   File "magic.py", line 254, in _create_filemagic     raise ValueError(mime_detected) ValueError: cannot open `foobar' (No such file or directory) >>>
(0000024) christos    2018-08-01 09:03	feedback timeout

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
11	[file] General	minor	always	2018-07-22 08:07	2018-08-01 09:03
Reporter:	cbiedl	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Differing results from magic_file() and magic_buffer()
Description:	The recent changes in file added inspection on the stat() system call result. This is of course not possible when magic_buffer() was call which does not know about the underlying file, if any. As one of several results, the test suite of Adam Hupp's python-magic breaks as it silently compares the result of both functions and fails on any difference: https://github.com/ahupp/python-magic/issues/173 Can you please add a warning to the documentation of magic_buffer() this might have a different result/less detailed result? One example is some ELF files where the executable bit is taken into consideration. And about that one, the gzip magic checks for the file size only AFAICT. Given the buffer size provided by any magic_buffer() caller, it should be possible to create a synthetic stat record containing at least that information. Cheers,     Christoph
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000014) christos    2018-07-25 06:24	Thanks. The ELF change that depended on stat(2) has been undone, but the magic_buffer and magic_file can still return different results, so I've documented it.
(0000023) christos    2018-08-01 09:03	feedback timeout

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
17	[file] General	minor	have not tried	2018-07-24 22:45	2018-08-01 09:02
Reporter:	cbiedl	Platform:	Linux
Assigned To:	christos	OS:	Debian
Priority:	normal	OS Version:	all
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	NULL check for ms in magic_setparam, magic_getparam?
Description:	Hello, all the public functions in magic.c that take a "struct magic_set" as parameter check at first whether it's NULL. However, magic_setparam and magic_getparam do not. By intention? Next step was to ask whether the "val" void pointer shouldn't be checked before dereferencing it. And all the other pointers that are provided in various functions.     Christoph
Tags:
Steps To Reproduce:
Additional Information:
System Description	Maintainer for the file package in Debian.
Attached Files:

Notes
(0000015) christos    2018-07-25 06:27	Thanks, for now I've added the ms == NULL tests for consistency.
(0000022) christos    2018-08-01 09:02	feedback timeout

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
18	[file] General	minor	always	2018-07-25 03:23	2018-08-01 08:51
Reporter:	anonymous	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	--mime-encoding reports a mangled string for .doc files
Description:	Background in https://stackoverflow.com/a/45177322/113632 Calling --mime on a .doc file prints: $ file --mime /tmp/example.doc /tmp/example.doc: application/msword; charset=binary Which leads me to believe --mime-encoding should print "binary", but instead it prints "application/mswordbinary": $ file --mime-encoding /tmp/example.doc /tmp/example.doc: application/mswordbinary Which appears to be the concatenation of the type and the encoding. Experimenting with several other file types all print *just* their encoding (e.g. binary, us-ascii, etc.).
Tags:
Steps To Reproduce:	1. Get a .doc file 2. Run `file --mime-encoding YOUR_FILE.doc`
Additional Information:
Attached Files:

Notes
(0000018) christos    2018-07-25 07:16	Fixed on HEAD, thanks!
(0000020) christos    2018-08-01 08:51	feedback timeout

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
20	[file] General	minor	always	2018-07-26 13:04	2018-08-01 08:51
Reporter:	anonymous	Platform:	x86_64
Assigned To:	christos	OS:	GNU/Linux
Priority:	normal	OS Version:	CentOS 7
Status:	resolved	Product Version:	5.34
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	--mime-encoding --uncompress reports a mangled string for .tar.gz files
Description:	Hello! Have a problem similar to https://bugs.astron.com/view.php?id=18, but for .tar.gz files instead of .doc Option --mime-encoding --uncompress (-z) for my .tar.gz file produces "application/x-tarbinary" $ file --mime-encoding --uncompress example.tar.gz example.tar.gz: application/x-tarbinary $ file --mime --uncompress example.tar.gz example.tar.gz: application/x-tar; charset=binary compressed-encoding=application/x-gzip; charset=binary Suppose that instead of "application/x-tarbinary" program should just return "binary" Tried with latest release 5.34 (compile from source) and with old pre-installed version 5.11
Tags:
Steps To Reproduce:	1. Create example.tar.gz archive with two non-empty text files in it; 2. Run `file --mime-encoding --uncompress example.tar.gz`
Additional Information:
Attached Files:

Notes
(0000019) christos    2018-08-01 08:51	fixed, thanks

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
8	[file] General	minor	N/A	2018-07-08 08:56	2018-07-10 03:16
Reporter:	valoq	Platform:
Assigned To:	christos	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Make Bugtracker publicly accessible
Description:	The bugtracker is currently only accessible after registration and login. This makes contributing and researching bugs/errors harder. Please consider to make the bugtracker publicly accessible without requiring a login
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000010) christos    2018-07-10 03:16	Added anonymous login.