[File] [PATCH] of Magdir/msdos,database DOS executable (COM) + *.CBT *.DRV - *.IMG; duplicates
Christos Zoulas
christos at zoulas.com
Tue Jul 12 18:57:56 UTC 2022
Committed, thanks!
christos
> On Jul 8, 2022, at 7:20 PM, Jörg Jenderek <joerg.jen.der.ek at gmx.net> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
>
> some days ago i handled some DOS executable (COM). Normally these
> have the file name extension COM. But some examples have not.
>
> When running file command version 5.42 with -k option on such
> examples and related files i get an output like:
>
> 360k-256.img: DOS/MBR boot sector,
> code offset 0x3c+2, OEM-ID "MTOO4018",
> Bytes/sector 256,
> sectors/cluster 2, FAT 1,
> root entries 56, sectors 1440 (volumes <=32 MB),
> Media descriptor 0xf9,
> sectors/FAT 3, sectors/track 9,
> serial number 0xaffebade, label: "720K256SIZE",
> FAT (12 bit), followed by FAT
> DOS floppy 720k
> DOS executable (COM)
> ADLIBG.COM: DOS executable (COM)
> CPQ0TD.DRV: DOS executable (COM)
> dBase III DBT, version number 0,
> next free block index 745
> Disk2.img: , code offset 0xf1+3, OEM-ID "EPS 3.10",
> sectors/cluster 2, root entries 112,
> sectors 720 (volumes <=32 MB),
> Media descriptor 0xfd,
> sectors/FAT 2, sectors/track 9,
> FAT (12 bit by descriptor), followed by FAT
> DOS/MBR boot sector DOS/MBR boot sector
> DOS executable (COM)
> , boot code
> Disk4.img: DOS/MBR boot sector,
> code offset 0x1c+2, OEM-ID "COMPAQ ",
> sectors/cluster 2, root entries 112,
> sectors 1440 (volumes <=32 MB),
> Media descriptor 0xf9,
> sectors/FAT 3, sectors/track 9,
> FAT (12 bit by descriptor), followed by FAT
> DOS floppy 720k
> DOS executable (COM)
> E30ODI.COM: DOS executable (COM)
> dBase III DBT, version number 0,
> next free block index 4076777,
> 1st item "\032;\016s\001t\022\211\016s
> FIXBIOS.COM: DOS executable (COM)
> IBM0MONO.DRV: DOS executable (COM)
> dBase III DBT, version number 0,
> next free block index 745
> INSTALL.COM: DOS executable (COM)
> PCDOS100.IMG: DOS executable (COM)
> RSSTUB.COM: DOS executable (COM)
> SDIAB4.DRV: DOS executable (COM)
> SPL0CPLS.DRV: DOS executable (COM)
> STACKER.COM: DR-DOS executable (COM)
> DOS executable (COM)
> TK-DOS11.img: DOS executable (COM)
> UMBFILL.COM: DOS executable (COM)
> UNI2ASCI.COM: DOS executable (COM)
> USBDRIVE.COM: DOS executable (COM)
> adressen.dbt: dBase III DBT, version number 0,
> next free block index 3,
> 1st item "2n email:root at localhost"
> balder10.img: DOS/MBR boot sector,
> code offset 0x3c+2, OEM-ID "FreeDOS ",
> root entries 224,
> sectors 2880 (volumes <=32 MB),
> sectors/FAT 9, sectors/track 18,
> serial number 0x3d241bda, label: "BALDER10 ",
> FAT (12 bit), followed by FAT
> DOS floppy 1440k,
> DOS/MBR hard disk boot sector DOS/MBR boot sector
> FREE-DOS Beta 0.9 Bootloader KERNEL.SYS
> DOS/MBR boot sector
> DOS executable (COM)
> , boot code
> boot_hybrid.img: DOS/MBR boot sector DOS/MBR boot sector
> DOS executable (COM)
> , boot code
> bootfloppy.img: Linux kernel x86 boot executable zImage,
> version 2.0.27 (root at srirangam.be.com) #1
> Mon Oct 20 15:29:23 PDT 1997,
> RO-rootFS, root_dev 0X1, Normal VGA
> DOS/MBR boot sector DOS/MBR boot sector
> DOS executable (COM)
> , boot code
> disk1.img: DOS executable (COM)
> drivedroid.img: DOS/MBR boot sector DOS/MBR boot sector
> DOS executable (COM)
> , boot code
> floppy_1.44.00.ima: DOS/MBR boot sector DOS/MBR boot sector
> DOS executable (COM)
> , boot code
> geodspms.img: DOS/MBR boot sector DOS/MBR boot sector
> Syslinux bootloader (version 3.10 or newer)
> DOS executable (COM)
> , boot code
> plpinst.com: Linux kernel x86 boot executable zImage,
> RW-rootFS,
> DOS/MBR boot sector DOS/MBR boot sector
> DOS executable (COM)
> , boot code
> sbm.cbt: DOS executable (COM)
> screate.sys: DR-DOS executable (COM)
> DOS executable (COM)
>
> When running with --extension and -k option i get output like:
>
> 360k-256.img: com
> ADLIBG.COM: com
> CPQ0TD.DRV: comdbt
> Disk2.img: com
> Disk4.img: com
> E30ODI.COM: comdbt
> FIXBIOS.COM: com
> IBM0MONO.DRV: comdbt
> INSTALL.COM: com
> PCDOS100.IMG: com
> RSSTUB.COM: com
> SDIAB4.DRV: com
> SPL0CPLS.DRV: com
> STACKER.COM: com
> TK-DOS11.img: com
> UMBFILL.COM: com
> UNI2ASCI.COM: com
> USBDRIVE.COM: com
> adressen.dbt: dbt
> balder10.img: com
> boot_hybrid.img: com
> bootfloppy.img: /dat/bin/lnx
> disk1.img: com
> drivedroid.img: com
> floppy_1.44.00.ima: com
> geodspms.img: com
> plpinst.com: /dat/bin/lnx
> sbm.cbt: com
> screate.sys: com
>
> The samples like STACKER.COM are also described by old code fragment
> inside Magdir/msdos with lines like:
> 0 ulelong 0xffff10eb DR-DOS executable (COM)
> This is only a special case of DOS executable starting with 8bit
> jump. This is done by line like:
> 0 byte 0xeb
> Unfortunately this is a weak magic, because this conflicts with magic
> leshort 0xn2eb of "SYMMETRY i386" handled by Magdir/sequent. In
> "newer" file command also the jump offset is checked by lines like:
>> 1 byte >-1
>>> (1.b+2) byte x
> By second line test for positive offset is done and by third line is
> checked that offset must be accessible. So hopefully this is now
> unique enough. If not then the bytes of next instruction must be
> considered. There exist only about a dozen of possibilities.
> So the old DR-DOS code fragments are not needed any more and can be
> removed.
>
> Unfortunately by these lines also many DOS disk images or boot
> sectors like example balder10.img are misidentified as "DOS
> executable (COM)" with an additional text "boot code". That part is
> triggered by line like:
>> 0x1FE leshort 0xAA55 \b, boot code
>
> So additional tests must be added before calling sub routine
> msdos-com. This may looks like:
>>>> 0x1FE leshort =0xAA55 0x1FE default x
>>>>> 0 use msdos-com
> If inspected sample does not contain a x86 boot signature it is
> often not a disk image and it is often an DOS COM executable. So for
> that case immediately call displaying sub routine. If it contains a
> boot signature it is here an disk image. That branch is dead or not
> used, because such disk image are already handled by
> Magdir/filesystems. Unfortunately the sub routine is not called after
> default directive for DOS executables with small sizes ( lower 512
> like FIXBIOS.COM with 50 bytes). I believe this is a BUG in file
> command! So maybe an expert should look after this problem.
> Furthermore very old DOS disk images (like TK-DOS11.img PCDOS100.IMG)
> have no boot signature and looks different from today DOS BIOS
> parameter block BPB). So these are not recognized by
> Magdir/filesystems.
>
> There the number of FAT is shown. 2 is the most used number.
> Sometimes value 1 is found for examples off RAM disks. In theory
> higher number are possible. This would raise redundancy compared with
> 2 FATs and waste more disc space. Furthermore on Wikipedia is written
> that some DOS operating systems support only two FATs in their
> built-in disk drive. So in real world example you will never found
> "high" number of FATs. So i use the number of FAT as additional test
> criterium.
>
> One branch is for examples with unrealistic high number of FATs. Here
> we find a few very old DOS disk images like disk1.img of MS-DOS 1.25
> (Corona Data Systems OEM) and PCDOS100.IMG of DOS 1.0 not conforming
> with standard BIOS Parameter Block (BPB). Here we also find a few
> non-DOS floppy images of systems like BeOS, Ventoy and drivedroid.
> After the test for number of FATs skip such disc images by looking
> for characteristic text near the beginning before calling sub routine
> for COM executable example like FIXBIOS.COM (with file size of 50
> bytes). This looks like:
>>>> 16 ubyte >3
>>>>> 2 string !DriveDroid
>>>>>> 15 string !Non\040System\040disk
>>>>>>> 6 string !read\040error\015
>>>>>>>> 24 string !\220\220\353I$\022\017
>>>>>>>>> 9 string !7-May-81
>>>>>>>>>> 3 string !\370sdfS\270
>>>>>>>>>>> 0 use msdos-com
>
> Another branch is for examples with low number (that means zero) of
> FATs. Most disc images here like boot.img (Ventoy 1.0.27) and
> geodspms.img (Syslinux) are skipped by looking for absence of boot
> signature (0xAA55). Here we also find a few very old DOS disk images
> like TK-DOS11.img and IBMDOS11.img (IBM DOS 1.10) not conforming with
> standard BIOS Parameter Block (BPB).
> As last test skip such disc images by looking for characteristic
> text before calling sub routine for COM executable examples like
> DEVICE.COM, INSTALL.COM (GAG 4.10) and WORD.COM (Word 1.15). This
> looks like:
>>>> 16 ubyte =0
>>>>> 0x1FE leshort =0xAA55
>>>>> 0x1FE default x
>>>>>> 395 string !ibmbio\040\040com
>>>>>>> 0 use msdos-com
>
> The third branch is for examples with "normal" number of FATs. Here
> disc images are skipped by test for absence of boot signature at
> end of sector and absence of file system type text for FAT. As last
> test skip remaining disc image like Disk4.img (MS-DOS 3.31 Compaq
> OEM) by looking for characteristic text near the beginning before
> calling sub routine for possible COM executable examples. This
> looks like:
>>>> 16 default x
>>>>> (11.s-2) uleshort !0xAA55
>>>>>> 54 string !FAT
>>>>>>> 3 string !COMPAQ\040\040
>>>>>>>> 0 use msdos-com
>
> The problem with disk images occur also for 16-bit jumps. And there
> more details about the BIOS parameter block (BPB) are shown. FAT
> volumes can contain an initial program loader (IPL) written in x86
> machine code. So this looks like a DOS executable.
>
> Because there exist some typical different starting bytes used by DOS
> COM executables show for control reason this information at the end
> of sub routine msdos-com by additional line like:
>> 0 ubelong x \b, start instruction %#8.8x
>
> The displaying part is done by sub routine msdos-com which starts
> with lines like:
> 0 name msdos-com
>> 0 byte x DOS executable (COM)
> !:mime application/x-dosexec
> !:ext com
> This now becomes like:
> 0 name msdos-com
>> 0 byte x DOS executable (
>
> To handle cases with unusual file name extension (not COM) some
> different branches must be inserted. Probably non COM extension is
> chosen because the program are used internal by other DOS tools and
> should not be called by user. The DRV samples are part of Lotus 123
> or Symphony spreadsheet suite. These are apparently driver for device
> s
> like printers. The names of such drivers look like Diablo, "COMPAQ
> Text Display", "IBM Monochrome Display" or "Plantronics ColorPlus"
> and are stored at offset 24 and padded with nil bytes til offset 64.
> The examples start with 16-bit jump instruction E9. So these are now
> handled by branch with lines like:
>> 0 byte =0xE9
>>> 56 quad =0
>>>> 24 regex =^[A-Z][A-Za-z\040]{5,21} \bLotus driver) %s
> !:mime application/x-dosexec
> !:ext drv
>
> Some COM executables with nil bytes like MODE.COM IBMDOS.COM (pcdos
> 3.31 ru Compaq) RSSTUB.COM (PC-DOS 2000 de) ACCESS.COM (Lotus
> Symphony 1) are handled by lines like:
>>>> 24 default x \bCOM)
> !:mime application/x-dosexec
> !:ext com
>
> In COMBOOT section on Syslinux wiki is written that a COMBOOT file
> which is not compatible with MS-DOS will usually have extension
> ".cbt" instead of ".com". Syslinux-specific API calls are executed
> using INT 22h. The INT 22h is also used by DOS for internal purposes.
> So look for such possible call by additional line at the end of sub
> routine by line like:
>> 1 search/0xc088 \xcd\x22 \b, maybe with interrupt 22h
> The line is true for the one CBT version of the smart boot manager
> (sbm.cbt). But it is also matched by some versions of DOS tools like
> COMMAND.COM, IBMDOS.COM, RECOVER.COM and E30ODI.COM. And it also true
> for FreeDOS UNI2ASCI.COM from USBDOS package. There this is matched
> by "Reversed Tilde Equals" inside Uni Code Characters table. So these
> are handled in branch for DOS executable with jump 16-bit and without
> nil padding. This looks like:
>>> 56 quad !0
>>>> 1 search/0xc088 \xcd\x22 \bCOM or COMBOOT 16-bit)
> !:mime application/x-dosexec
> !:ext com/cbt
>>>> 1 default x COM)
> !:mime application/x-dosexec
> !:ext com
> Maybe somebody knows an additional step to distinguish COMboot from
> pure DOS executables.
>
> The Stacker disk compression module screate.sys ( with characteristic
> string ?STACVOL near the beginning) is handled by branch for DOS
> executables without jump 16-bit instruction. This now looks like:
>> 0 byte !0xE9
>>> 10 string =?STACVOL \bSCREATE.SYS)
> !:mime application/x-dosexec
> !:ext sys
>
> Then there are examples of DOS executable starting with 16-bit JUMP
> instruction. This is done by line like:
> 0 byte 0xe9
> Unfortunately this is a weak magic. In "newer" file command also the
> jump offset is checked by lines.
> One branch for examples with positive offsets look like:
>> 1 short >-1
>>> (1.s+3) byte x
>>>> 0 use msdos-com
> The offsets are relative. So to get the real offset you must one for
> the jump instruction (E9 value) and two for the 16-bit offset value
> to get real offset. If this code is accessible is tested by third
> line. Only a dozen of values are possible here (with hexadecimal
> values like: 06 1e 0e 2e 60 8c 8d b4 ba be e8 fc).
> COM executable are made for intel x86 with little endian architecture
> .
> So when you run such magic lines on computer with big endian
> architecture you do not get expected results. So i think the correct
> line must look like:
>> 1 leshort >-1
>
> Unfortunately by these lines also some DOS disk images or boot
> sectors with "code offset" and "+3" like example Disk2.img are
> misidentified as "DOS executable (COM)". So additional tests must
> be added before calling sub routine msdos-com.
>
> I use the same steps as for 8-bit jumps. The branch for examples
> with "normal" number of FATs and positiv offsets goes this ways. If
> examples has invalid low media descriptor then it is not a disk
> image and it is a DOS executable. If examples has invalid sector
> size not a power of 2 from 32-32768 then it is not a disk image and
> it must be DOS executable like LEARN.COM (Word 1.15). This looks like
> :
>>>> 16 default x
>>>>> 21 ubyte <0xE5
>>>>>> 0 use msdos-com
>>>>> 21 ubyte >0xE4
>>>>>> 11 uleshort&0x001f !0
>>>>>>> 0 use msdos-com
>
> One branch for examples with negative offsets look like:
>> 1 short <-259
>>> (1,s+65539) byte x
>>>> 0 use msdos-com
>
> The offsets are relative. So to get the real offset you must add one
> for the jump instruction (E9 value) and two for the 16-bit offset
> value to get real offset. If you found examples with small negative
> value you would jump into the PSP area ( with length 255 at the
> beginning). That is not possible for real COM executables.
>
> COM executable are made for intel x86 with little endian
> architecture. So when you run such magic lines on computer with big
> endian architecture you do not get expected results. Such
> candidates are HIDSUPT1.COM, USBDRIVE.COM and USBSUPT1.COM (part of
> FreeDOS USBDOS package) or WORD.COM ( from Microsoft Word version
> 4). So i think the correct line must look like:
>> 1 leshort <-259
> To check that the offset is accessible you must also add 10000h to
> jump at end of 64 KiB segment to get real offset. But in this third
> test line a comma character is used. That means offset is treated
> signed.
>
> Some executables are misidentified by Magdir/database as "dBase III
> DBT". Unfortunately xbase memo files have no strong magic, but
> luckily the displaying part is done by subroutine
> dbase3-memo-print. At the end of that sub routine the first memo
> item is shown by line like:
>> 512 string >\0 \b, 1st item "%s"
> For real examples i get ASCII text like "2n email:root at localhost" in
> example adressen.dbt.
> Before calling this subroutine in one branch the second character of
> possible first memo item was tested for not "too low" by lines like:
>>>>>>>>>>> 513 ubyte >037
>>>>>>>>>>>> 0 use dbase3-memo-print
> So bad example WinStore.App.exe was skipped. There exist another
> branch before calling this subroutine. There the same problem
> occurred. That is the branch skipping OMF libraries (like WATTCPWL.LI
> B
> ZLIB.LIB) and some router gluon firmware. There also the first
> character of first item was tested for "not too low" (is printable).
> To skip misidentified COM executables (E30ODI.COM with 1st item like
> "\032;\016s") i use this additional check also here. This now looks
> like:
>>>>>>>>>>> 513 ubyte >037
>>>>>>>>>>>> 512 ubyte >037
>>>>>>>>>>>>> 0 use dbase3-memo-print
>
> After applying the above mentioned modifications by patches
> file-5.42-msdos-com-jump.diff and file-5.42-database-dbt.diff
> and using Magdir/filesystems with Magdir/linux then
> misidentifications vanish and some more details are shown. This now
> looks with -k option like:
>
> 360k-256.img: DOS/MBR boot sector,
> code offset 0x3c+2, OEM-ID "MTOO4018",
> Bytes/sector 256,
> sectors/cluster 2, FAT 1,
> root entries 56, sectors 1440 (volumes <=32 MB),
> Media descriptor 0xf9,
> sectors/FAT 3, sectors/track 9,
> serial number 0xaffebade, label: "720K256SIZE",
> FAT (12 bit), followed by FAT
> DOS floppy 720k
> ADLIBG.COM: DOS executable (COM)
> , start instruction 0xe9581144
> CPQ0TD.DRV: DOS executable (Lotus driver)
> COMPAQ Text Display
> , start instruction 0xe9020000
> Disk2.img: , code offset 0xf1+3, OEM-ID "EPS 3.10",
> sectors/cluster 2, root entries 112,
> sectors 720 (volumes <=32 MB),
> Media descriptor 0xfd,
> sectors/FAT 2, sectors/track 9,
> FAT (12 bit by descriptor), followed by FAT
> DOS/MBR boot sector DOS/MBR boot sector
> Disk4.img: DOS/MBR boot sector,
> code offset 0x1c+2, OEM-ID "COMPAQ ",
> sectors/cluster 2, root entries 112,
> sectors 1440 (volumes <=32 MB),
> Media descriptor 0xf9,
> sectors/FAT 3, sectors/track 9,
> FAT (12 bit by descriptor), followed by FAT
> DOS floppy 720k
> E30ODI.COM: DOS executable (COM)
> , maybe with interrupt 22h
> , start instruction 0xe9343e00
> FIXBIOS.COM: DOS executable (COM)
> , start instruction 0xeb0b80fc
> IBM0MONO.DRV: DOS executable (Lotus driver)
> IBM Monochrome Display
> , start instruction 0xe9020000
> INSTALL.COM: DOS executable (COM)
> , start instruction 0xeb1e9000
> PCDOS100.IMG: data
> RSSTUB.COM: DOS executable (COM)
> , start instruction 0xe9500243
> SDIAB4.DRV: DOS executable (Lotus driver)
> Diablo
> , start instruction 0xe9050400
> SPL0CPLS.DRV: DOS executable (Lotus driver)
> Plantronics ColorPlus
> , start instruction 0xe91e0000
> STACKER.COM: DOS executable (COM)
> , start instruction 0xeb10ffff
> TK-DOS11.img: data
> UMBFILL.COM: DOS executable (COM)
> , start instruction 0xe9350000
> UNI2ASCI.COM: DOS executable (COM or COMBOOT 16-bit)
> , maybe with interrupt 22h
> , start instruction 0xe9ae530d
> USBDRIVE.COM: DOS executable (COM)
> , start instruction 0xe907be0d
> adressen.dbt: dBase III DBT, version number 0,
> next free block index 3,
> 1st item "2n email:root at localhost"
> balder10.img: DOS/MBR boot sector,
> code offset 0x3c+2, OEM-ID "FreeDOS ",
> root entries 224,
> sectors 2880 (volumes <=32 MB),
> sectors/FAT 9, sectors/track 18,
> serial number 0x3d241bda, label: "BALDER10 ",
> FAT (12 bit), followed by FAT
> DOS floppy 1440k,
> DOS/MBR hard disk boot sector DOS/MBR boot sector
> FREE-DOS Beta 0.9 Bootloader KERNEL.SYS
> DOS/MBR boot sector
> boot_hybrid.img: DOS/MBR boot sector DOS/MBR boot sector
> bootfloppy.img: Linux kernel x86 boot executable zImage,
> version 2.0.27 (root at srirangam.be.com) #1
> Mon Oct 20 15:29:23 PDT 1997,
> RO-rootFS, root_dev 0X1, Normal VGA
> DOS/MBR boot sector DOS/MBR boot sector
> disk1.img: data
> drivedroid.img: DOS/MBR boot sector DOS/MBR boot sector
> floppy_1.44.00.ima: DOS/MBR boot sector DOS/MBR boot sector
> geodspms.img: DOS/MBR boot sector DOS/MBR boot sector
> Syslinux bootloader (version 3.10 or newer)
> plpinst.com: Linux kernel x86 boot executable zImage,
> RW-rootFS,
> DOS/MBR boot sector DOS/MBR boot sector
> DOS executable (COM)
> , boot code
> , start instruction 0xe9810248
> sbm.cbt: DOS executable (COM or COMBOOT 16-bit)
> , maybe with interrupt 22h
> , start instruction 0xe9fd0b90
> screate.sys: DOS executable (SCREATE.SYS)
> , start instruction 0xeb10ffff
>
>
> With --extension option i now get nearly expected results. This now
> looks like:
>
> 360k-256.img: ???
> ADLIBG.COM: com
> CPQ0TD.DRV: drv
> Disk2.img: ???
> Disk4.img: ???
> E30ODI.COM: com
> FIXBIOS.COM: com
> IBM0MONO.DRV: drv
> INSTALL.COM: com
> PCDOS100.IMG: ???
> RSSTUB.COM: com
> SDIAB4.DRV: drv
> SPL0CPLS.DRV: drv
> STACKER.COM: com
> TK-DOS11.img: ???
> UMBFILL.COM: com
> UNI2ASCI.COM: com/cbt
> USBDRIVE.COM: com
> adressen.dbt: dbt
> balder10.img: ???
> boot_hybrid.img: ???
> bootfloppy.img: /dat/bin/lnx
> disk1.img: ???
> drivedroid.img: ???
> floppy_1.44.00.ima: ???
> geodspms.img: ???
> plpinst.com: /dat/bin/lnx
> sbm.cbt: com/cbt
> screate.sys: sys
>
> I hope my diff files can be applied in future version of file
> utility. I will try to improve the "DOS/MBR boot sector" parts inside
> Magdir/filesystems in a future session.
>
> With best wishes
> Jörg Jenderek
> - --
> Jörg Jenderek
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iF0EARECAB0WIQS5/qNWKD4ASGOJGL+v8rHJQhrU1gUCYsi7xgAKCRCv8rHJQhrU
> 1hMrAJ9Cv6v1SM2B+3kYcaSixaG8MvCvVQCfaiJ0d7tAvFYw31pk5H0WBHIrQD4=
> =ZB3V
> -----END PGP SIGNATURE-----
> <file-5_42-database-dbt_diff.DEFANGED-153086><file-5_42-database-dbt_diff_sig.DEFANGED-153087><file-5_42-msdos-com-jump_diff.DEFANGED-153088><file-5_42-msdos-com-jump_diff_sig.DEFANGED-153089>--
> File mailing list
> File at astron.com
> https://mailman.astron.com/mailman/listinfo/file
> <sanitizer.log>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP
URL: <https://mailman.astron.com/pipermail/file/attachments/20220712/5b147060/attachment.asc>
More information about the File
mailing list