[jira] [Commented] (TIKA-3784) Detector returns "application/x-x509-key" when scanning a .p12 file

2022-06-02 Thread Tim Allison (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-3784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17545537#comment-17545537
 ] 

Tim Allison commented on TIKA-3784:
---

[~nick], any recommendations?

> Detector returns "application/x-x509-key" when scanning a .p12 file
> ---
>
> Key: TIKA-3784
> URL: https://issues.apache.org/jira/browse/TIKA-3784
> Project: Tika
>  Issue Type: Bug
>  Components: detector
>Affects Versions: 1.26
>Reporter: Matthias Hofbauer
>Priority: Critical
>
> We are using tika to check if the MIME type of the file extensions matches 
> with the MIME type of the file content.
> After our upgrade from tika-core 1.22 to 1.26 our logic does not work anymore 
> for certificates of type .p12, .pfx, .cer, .der.
> For the .p12 and .pfx extension the MIME type is "application/x-pkcs12" but 
> the tika detector returns "application/x-x509-key" instead.
> After checking the tika-mimetype.xml and comparing it to my .p12 file I found 
> the following MIME magic which explains why I got these types back.
> {code:xml}
> 
>     
>     
>     
>     
>     
>                      mask="0x00FC" offset="0"/>
>                      mask="0xFC" offset="0"/>
>     
>  {code}



--
This message was sent by Atlassian Jira
(v8.20.7#820007)


[jira] [Commented] (TIKA-3784) Detector returns "application/x-x509-key" when scanning a .p12 file

2022-06-05 Thread Nick Burch (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-3784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17550223#comment-17550223
 ] 

Nick Burch commented on TIKA-3784:
--

We don't currently have any Mime Magic for PKCS12 files

Based on 
[https://stackoverflow.com/questions/33239875/jks-bks-and-pkcs12-file-formats] 
it won't be an easy one to cope with, since we don't currently have an ASN.1 
container detector

I think we can potentially get away with a slightly hacky approach similar to 
the PKCS7 signature, where we look for a few variants and hope the right entry 
comes first... "openssl asn1parse" should help with working out what to look for

(Assuming no-one has a bit of time to knock up an ASN1 container detector based 
on the BouncyCastle ASN.1 using an approach similar to 
[https://stackoverflow.com/questions/10190795/parsing-asn-1-binary-data-with-java]
 )

> Detector returns "application/x-x509-key" when scanning a .p12 file
> ---
>
> Key: TIKA-3784
> URL: https://issues.apache.org/jira/browse/TIKA-3784
> Project: Tika
>  Issue Type: Bug
>  Components: detector
>Affects Versions: 1.26
>Reporter: Matthias Hofbauer
>Priority: Critical
>
> We are using tika to check if the MIME type of the file extensions matches 
> with the MIME type of the file content.
> After our upgrade from tika-core 1.22 to 1.26 our logic does not work anymore 
> for certificates of type .p12, .pfx, .cer, .der.
> For the .p12 and .pfx extension the MIME type is "application/x-pkcs12" but 
> the tika detector returns "application/x-x509-key" instead.
> After checking the tika-mimetype.xml and comparing it to my .p12 file I found 
> the following MIME magic which explains why I got these types back.
> {code:xml}
> 
>     
>     
>     
>     
>     
>                      mask="0x00FC" offset="0"/>
>                      mask="0xFC" offset="0"/>
>     
>  {code}



--
This message was sent by Atlassian Jira
(v8.20.7#820007)


[jira] [Commented] (TIKA-3784) Detector returns "application/x-x509-key" when scanning a .p12 file

2022-06-05 Thread Hudson (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-3784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17550231#comment-17550231
 ] 

Hudson commented on TIKA-3784:
--

SUCCESS: Integrated in Jenkins build Tika » tika-main-jdk8 #629 (See 
[https://ci-builds.apache.org/job/Tika/job/tika-main-jdk8/629/])
Tests for encrypted RSA keys in PEM and DER, plus a disabled PKCS12 test 
pending TIKA-3784 (nick: 
[https://github.com/apache/tika/commit/6bf9ee120c2845ccdf61207322dcea2373388e75])
* (edit) 
tika-parsers/tika-parsers-standard/tika-parsers-standard-package/src/test/java/org/apache/tika/mime/TestMimeTypes.java


> Detector returns "application/x-x509-key" when scanning a .p12 file
> ---
>
> Key: TIKA-3784
> URL: https://issues.apache.org/jira/browse/TIKA-3784
> Project: Tika
>  Issue Type: Bug
>  Components: detector
>Affects Versions: 1.26
>Reporter: Matthias Hofbauer
>Priority: Critical
>
> We are using tika to check if the MIME type of the file extensions matches 
> with the MIME type of the file content.
> After our upgrade from tika-core 1.22 to 1.26 our logic does not work anymore 
> for certificates of type .p12, .pfx, .cer, .der.
> For the .p12 and .pfx extension the MIME type is "application/x-pkcs12" but 
> the tika detector returns "application/x-x509-key" instead.
> After checking the tika-mimetype.xml and comparing it to my .p12 file I found 
> the following MIME magic which explains why I got these types back.
> {code:xml}
> 
>     
>     
>     
>     
>     
>                      mask="0x00FC" offset="0"/>
>                      mask="0xFC" offset="0"/>
>     
>  {code}



--
This message was sent by Atlassian Jira
(v8.20.7#820007)


[jira] [Commented] (TIKA-3784) Detector returns "application/x-x509-key" when scanning a .p12 file

2024-02-09 Thread Tim Allison (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-3784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816115#comment-17816115
 ] 

Tim Allison commented on TIKA-3784:
---

Based on this: 
https://stackoverflow.com/questions/30483489/how-to-decode-asn-1-data-in-java

If we parsed the ASN1, what would be look for? Does BouncyCastle have a 
detector?

> Detector returns "application/x-x509-key" when scanning a .p12 file
> ---
>
> Key: TIKA-3784
> URL: https://issues.apache.org/jira/browse/TIKA-3784
> Project: Tika
>  Issue Type: Bug
>  Components: detector
>Affects Versions: 1.26
>Reporter: Matthias Hofbauer
>Priority: Critical
>
> We are using tika to check if the MIME type of the file extensions matches 
> with the MIME type of the file content.
> After our upgrade from tika-core 1.22 to 1.26 our logic does not work anymore 
> for certificates of type .p12, .pfx, .cer, .der.
> For the .p12 and .pfx extension the MIME type is "application/x-pkcs12" but 
> the tika detector returns "application/x-x509-key" instead.
> After checking the tika-mimetype.xml and comparing it to my .p12 file I found 
> the following MIME magic which explains why I got these types back.
> {code:xml}
> 
>     
>     
>     
>     
>     
>                      mask="0x00FC" offset="0"/>
>                      mask="0xFC" offset="0"/>
>     
>  {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (TIKA-3784) Detector returns "application/x-x509-key" when scanning a .p12 file

2024-02-09 Thread Tim Allison (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-3784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816191#comment-17816191
 ] 

Tim Allison commented on TIKA-3784:
---

[~nick] (and cc [~tom_1st] from TIKA-4194), I agree that parsing these things 
would probably be best as a container detector. When I run AS1Dump on one of 
the p12 files, I get this:

{noformat}
Sequence
Integer(3)
Sequence
ObjectIdentifier(1.2.840.113549.1.7.1)
Tagged [CONTEXT 0]
DER Octet String[2603] 
Sequence
Sequence
Sequence
ObjectIdentifier(2.16.840.1.101.3.4.2.3)
NULL
DER Octet String[64] 
DER Octet String[64] 
Integer(100)
{noformat}

Is there anything in there I can use to detect p12?

> Detector returns "application/x-x509-key" when scanning a .p12 file
> ---
>
> Key: TIKA-3784
> URL: https://issues.apache.org/jira/browse/TIKA-3784
> Project: Tika
>  Issue Type: Bug
>  Components: detector
>Affects Versions: 1.26
>Reporter: Matthias Hofbauer
>Priority: Critical
>
> We are using tika to check if the MIME type of the file extensions matches 
> with the MIME type of the file content.
> After our upgrade from tika-core 1.22 to 1.26 our logic does not work anymore 
> for certificates of type .p12, .pfx, .cer, .der.
> For the .p12 and .pfx extension the MIME type is "application/x-pkcs12" but 
> the tika detector returns "application/x-x509-key" instead.
> After checking the tika-mimetype.xml and comparing it to my .p12 file I found 
> the following MIME magic which explains why I got these types back.
> {code:xml}
> 
>     
>     
>     
>     
>     
>                      mask="0x00FC" offset="0"/>
>                      mask="0xFC" offset="0"/>
>     
>  {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (TIKA-3784) Detector returns "application/x-x509-key" when scanning a .p12 file

2024-02-09 Thread Tim Allison (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-3784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816192#comment-17816192
 ] 

Tim Allison commented on TIKA-3784:
---

Or verbose mode:

{noformat}
Sequence
Integer(3)
Sequence
ObjectIdentifier(1.2.840.113549.1.7.1)
Tagged [CONTEXT 0]
DER Octet String[2603] 

30820a273082043d06092a864886f70d010706a082042e3082042a02010030820'0=*H.0*0

042306092a864886f70d01070130819106092a864886f70d01050d3081833062#*H0*H00b

06092a864886f70d01050c305504409230fd49789d0b306756c36540fc618f09
*H0U@0Ix0gVe@a

05fc94d32f934c12312e92b80a737058f3919dc41b024b14c9a3eb45922628b5/L1.spXKE&(

14f013842a44af174b26b7f30dd88402030f4240300c06082a864886f70d020b*DK&B@0*H

0500301d060960864801650304012a0410121c481cab9a38375a29a8eb4d47030`He*H87Z)MG

f380820380b4abd22fed0e82635ae69b52d94ea261ce899cb7ceaa833706d6e6/cZRNa7

6c8a20fccd910e314306f737506a41a83b87db4ada1aec0bf274eccf7743e4b3l 
1C7PjA;JtwC

f4e939f34d5b61a87521e5ac5fd7a558791d0de123097ccd020cf33e82767403
9M[au!_Xy#|>vt

7058be6836a97220209c99c18997dd4aaaf6376e8daea39e92baacec67b89a14pXh6r  J7ng

2b4ac3693ec47b51d8cc61b991da01f35628fdae4d1009dd3c8dbc01c062e706+Ji>{QaV(M/

1c6aa5834cf8dc0879f2cb1168be6449b53fbd6dc9e62ca8256e6da3a2d19906jLyhdI?m,%nm

5cdbdeaec0999743c9020f154155b717b6b1678bf987794e60608fefd0571ae1\CAUgyN``W

6f8123f30c45d02d19b2d9e854343ab37cd5798d94f63898601a37fd019c9bc8o#E-T4:|y8`7

881f6c6efebf91df9666a5e1b177e3deb8eb1ce4ed42b6a73ec771540d9dd419lnfwB>qT

f46d420c1ef3128a550a5cc5f36ef402f72710e8ac6a7661fb7d3387a5f84de5mBU\n'jva}3M

3c1424db71d44382a19b7a70f94e06aff9d2c88b213daaf437f6d524d22524c5
<$qCzpN!=7$%$

cb7d9d6ba2cea9ebcb99dffeb8fb0d9138075e0ef8f12035dabfe289c2d73448}k8^ 54H

e815bfb34eecd8d7d77a6beda1b9db71ff083e92afa92e32937c54c492c8847eNzkq>.2|T~

b1244ee5ee0ccbb2fbe0f7bf277cd3ea6c53123e96feea6866d6d8d9af9c4b94$N'|lS>hfK

bc07ee4a285459b6a221bf04f7bef730efb108db1a157e9a4d622122f440bf9fJ(TY!0~Mb!"@

248109387f9362ed59ed44686828f3ff060888bd34a76350aa680ac8b1b7e0c1$8bYDhh(4cPh

d0c05d2a3ee91a346413511b48362e58dffbeae55789ae179307032e9fabc033
]*>4dQH6.XW.3

8e2d1a16af308205e206092a864886f70d010701a08205d3048205cf308205cb-0*H0

308205c7060b2a864886f70d010c0a0102a082056c3082056830819106092a860*Hl0h0*

4886f70d01050d308183306206092a864886f70d01050c305504407e483ed9a8H00b*H0U@~H>

2f508286cc2b702fce42d3f49e1212899c2306da11428d0a2d0c5753842afea9/P+p/B#B-WS*

318e126f5a9210a35eef41201ade1621342275bbdc1e1203c5c3ac02030f42401oZ^A !4"uB@

300c06082a864886f70d020b0500301d060960864801650304012a04105e90cb0*H0`He*^

77a055e0be074a4e8f80f84aee048204d00e38277e485269d64f955a49ed5247
wUJNJ8'~HRiOZIRG

e5a24f6717b07a91d15574d46bd2b442d0a13ab34fec55be179bfdf6eae15eeeOgzUtkB:OU^

01aa261854275d2d93be49898b759880b8f47249b04d735803b6f16102da8909
&T']-IurIMsXa

cf74c73172a798a209943e65efec491a3bf09ccf022acdfb1e0bb6fd9a50a1d9t1r>eI;*P

bc01c848dbbb7c8e66fa0349ef29445ada763b62427b00fa87bc2846d1b9f690
H|fI)DZv;bB{(F

0066d4a6d2ead07f7b1b83f8a8f7ca69200a45a5f39ecb0476f9cf09d57b2e63f{i Ev{.c

da8a0faf0faf1fb0e924716695d9f207f8fc977ba7793e1aa65efe7652fdf83d$qf{y>^vR=

750738ce443365ae96b94f275ce0e13af5f2cb400722053a9f618d56f108314b
u8D3eO'\:@":aV1K

b7183342c26f9fde3a075d92597c509fd570bd9917d773921445e03eaf00fe24
3Bo:]Y|PpsE>$

48227e6d4492dc51e975dfde2fac15e8c9b1ee812958bd00200177228c39a0c1H"~mDQu/)X 
w"9

b8d1b92545153cfd3064dc8d464cfada545d7ed8b96b8cbeb58d4ecb19572633
%E<0dFLT]~kNW&3

82d86f727c4a5cbebf127c9de46e6566e61ef779922903c3df79d0c84743cf25
or|J\|nefy)yGC%

e9287c48c8535bf71cf6b0104160a762f403ce7da791e3c38781bcffc1537f16(|HS[A`b}S

bd6d9d9a55ac3475d0a82e8aa9d98e10525fc2795ebeef45c9bf50924059b01d
mU4u.R_y^EP@Y

f715839f37e44969f3ec248f19c030cdd0a693d5749f7686b704d27f1a52ca007Ii$0tvR

98d6e856d4efece298383aecfa82aa19bc98eef9e9f333a656479ffa0dd85c6eV8:3VG\n

df0fa6cd82d1c5115a507b9abebfb716d03729cc196d41382890482e0259b9f5ZP{7)mA8(H.Y

4016a1b718ac074ba88aa9a06d2dd6134578caeb7513b64a5e93c4970b8f9460@Km

[jira] [Commented] (TIKA-3784) Detector returns "application/x-x509-key" when scanning a .p12 file

2024-02-09 Thread Tim Allison (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-3784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816193#comment-17816193
 ] 

Tim Allison commented on TIKA-3784:
---

ObjectIdentifiers? 1.2.840.113549.1.7.1 
(https://oidref.com/1.2.840.113549.1.7.1), but that's just pkcs7 data type, 
nothing specific to pkcs12?

> Detector returns "application/x-x509-key" when scanning a .p12 file
> ---
>
> Key: TIKA-3784
> URL: https://issues.apache.org/jira/browse/TIKA-3784
> Project: Tika
>  Issue Type: Bug
>  Components: detector
>Affects Versions: 1.26
>Reporter: Matthias Hofbauer
>Priority: Critical
>
> We are using tika to check if the MIME type of the file extensions matches 
> with the MIME type of the file content.
> After our upgrade from tika-core 1.22 to 1.26 our logic does not work anymore 
> for certificates of type .p12, .pfx, .cer, .der.
> For the .p12 and .pfx extension the MIME type is "application/x-pkcs12" but 
> the tika detector returns "application/x-x509-key" instead.
> After checking the tika-mimetype.xml and comparing it to my .p12 file I found 
> the following MIME magic which explains why I got these types back.
> {code:xml}
> 
>     
>     
>     
>     
>     
>                      mask="0x00FC" offset="0"/>
>                      mask="0xFC" offset="0"/>
>     
>  {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (TIKA-3784) Detector returns "application/x-x509-key" when scanning a .p12 file

2024-02-09 Thread Tim Allison (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-3784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816198#comment-17816198
 ] 

Tim Allison commented on TIKA-3784:
---

I've just attached a dump of running that on all the *.p12 files in the repo 
mentioned on TIKA-4194

> Detector returns "application/x-x509-key" when scanning a .p12 file
> ---
>
> Key: TIKA-3784
> URL: https://issues.apache.org/jira/browse/TIKA-3784
> Project: Tika
>  Issue Type: Bug
>  Components: detector
>Affects Versions: 1.26
>Reporter: Matthias Hofbauer
>Priority: Critical
> Attachments: dump_p12s.txt
>
>
> We are using tika to check if the MIME type of the file extensions matches 
> with the MIME type of the file content.
> After our upgrade from tika-core 1.22 to 1.26 our logic does not work anymore 
> for certificates of type .p12, .pfx, .cer, .der.
> For the .p12 and .pfx extension the MIME type is "application/x-pkcs12" but 
> the tika detector returns "application/x-x509-key" instead.
> After checking the tika-mimetype.xml and comparing it to my .p12 file I found 
> the following MIME magic which explains why I got these types back.
> {code:xml}
> 
>     
>     
>     
>     
>     
>                      mask="0x00FC" offset="0"/>
>                      mask="0xFC" offset="0"/>
>     
>  {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (TIKA-3784) Detector returns "application/x-x509-key" when scanning a .p12 file

2024-02-12 Thread Nick Burch (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-3784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816788#comment-17816788
 ] 

Nick Burch commented on TIKA-3784:
--

>From [https://datatracker.ietf.org/doc/rfc7292/] it looks like PKCS12 is based 
>on PKCS7, so that's expected. There's a few more types defined in 
>[https://www.rfc-editor.org/rfc/rfc7292.html#appendix-D] - not sure if we can 
>find any of those to match on?

Thought [https://www.cs.auckland.ac.nz/~pgut001/pubs/pfx.html] does suggest 
this isn't an ideal format...

> Detector returns "application/x-x509-key" when scanning a .p12 file
> ---
>
> Key: TIKA-3784
> URL: https://issues.apache.org/jira/browse/TIKA-3784
> Project: Tika
>  Issue Type: Bug
>  Components: detector
>Affects Versions: 1.26
>Reporter: Matthias Hofbauer
>Priority: Critical
> Attachments: dump_p12s.txt
>
>
> We are using tika to check if the MIME type of the file extensions matches 
> with the MIME type of the file content.
> After our upgrade from tika-core 1.22 to 1.26 our logic does not work anymore 
> for certificates of type .p12, .pfx, .cer, .der.
> For the .p12 and .pfx extension the MIME type is "application/x-pkcs12" but 
> the tika detector returns "application/x-x509-key" instead.
> After checking the tika-mimetype.xml and comparing it to my .p12 file I found 
> the following MIME magic which explains why I got these types back.
> {code:xml}
> 
>     
>     
>     
>     
>     
>                      mask="0x00FC" offset="0"/>
>                      mask="0xFC" offset="0"/>
>     
>  {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (TIKA-3784) Detector returns "application/x-x509-key" when scanning a .p12 file

2024-02-12 Thread Lonzak (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-3784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816811#comment-17816811
 ] 

Lonzak commented on TIKA-3784:
--

PKCS12 is not the easiest format :-|

The oid for pkcs12 starts with "1.2.840.113549.1.12"

I decoded one pkcs12 example (from redhat) and got the following:
{code:java}

 3
 
  1.2.840.113549.1.7.1
  
   
    
     
      
       1.2.840.113549.1.7.1
       
        
         
          
           
            1.2.840.113549.1.12.10.1.2
            
             
              
               1.2.840.113549.1.12.1.3
               
                0xC8CCE579B6DE5B393F7C4885714C04BA
                2000
               
              
              0x...(shortened fro readability)
             
            
            
             
              1.2.840.113549.1.9.20
              
               0x00630061
              
             
             
              1.2.840.113549.1.9.21
              
               
0x0CDA92EB395D4697A9D178352AF6B2BF06947888
              
             
            
           
          
         
        
       
      
      
       1.2.840.113549.1.7.6
       
        
         
         
          1.2.840.113549.1.7.1
          
           1.2.840.113549.1.12.1.6
           
            0x7F432D60BCD2888476E6CB9CD2BC69F1
            2000
           
          
          
           0x...(shortened fro readability)
           0x0E8E4C15DCB1D87F
          
         
        
       
      
     
    
   
  
 
 
  
   
    1.3.14.3.2.26
    
   
   0x6DFFA14B5A8A32A87DAD2CFCE1EAEBDAFB89C897
  
  0x826699C21B9A4C9E3E608D3C8FBD2310
  2000
 
 {code}
The following things points to a pkcs12 format:
 # Presence of PKCS#12-specific object identifiers (OIDs):
 ## PKCS#12 Bag Types: presence of OIDs such as 1.2.840.113549.1.12.10.1.x, 
which indicate different types of key and certificate bags (KeyBags, CertBags, 
etc.).
 ## PKCS#12 PbeIds: Encryption and hashing OIDs such as 
1.2.840.113549.1.12.1.x, which indicate the use of specific encryption 
mechanisms 
 # Use of encryption schemes:
 ## Recognize encryption schemes, especially those that are typical for 
PKCS#12, such as pbeWithSHAAnd3-KeyTripleDES-CBC and pbeWithSHAAnd40BitRC2-CBC. 
These schemes are crucial for the security of PKCS#12 files and a clear 
indication of their presence.
 #  Structure of the file:
 ## Analyzing the file structure for multi-level nested SEQUENCE and 
OCTET_STRING elements, which are typically used to store encrypted private keys 
and certificates. The complexity of this structure is characteristic of PKCS#12 
files.
 # Specific attributes:
 ## PKCS#9 attributes such as friendlyName (OID 1.2.840.113549.1.9.20) and 
localKeyID (OID 1.2.840.113549.1.9.21) are commonly used to provide metadata 
for keys and certificates within the container.
 #  ... and more

 

However since we are already talking about Libraries - Standard Java Crypto and 
BouncyCastle have all this already inside. They are parsing the structures, 
analyze and use it. So using one of these two would be the easiest solution 
imho. I have never written a Detector so please excuse my ignorance:
{code:java}
public class PKCS12Detector implements Detector {    
private static final long serialVersionUID = -8414458255467101503L;
    private static final MediaType PKCS12_MEDIA_TYPE = 
MediaType.application("x-pkcs12");    

@Override
    public MediaType detect(InputStream input, Metadata metadata) {
        try {
            KeyStore keyStore = KeyStore.getInstance("PKCS12");
            keyStore.load(input, null);
            return PKCS12_MEDIA_TYPE; // success
        }
        catch (Exception e) {
            return MediaType.OCTET_STREAM; // something else
        }
    }
} {code}
A bouncy castle one would look quite similar...

> Detector returns "application/x-x509-key" when scanning a .p12 file
> ---
>
> Key: TIKA-3784
> URL: https://issues.apache.org/jira/browse/TIKA-3784
> Project: Tika
>  Issue Type: Bug
>  Components: detector
>Affects Versions: 1.26
>Reporter: Matthias Hofbauer
>Priority: Critical
> Attachments: dump_p12s.txt
>
>
> We are using tika to check if the MIME type of the file extensions matches 
> with the MIME type of the file content.
> After our upgrade from tika-core 1.22 to 1.26 our logic does not work anymore 
> for certificates of type .p12, .pfx, .cer, .der.
> For the .p12 and .pfx extension the MIME type is "application/x-pkcs12" but 
> the tika detector returns "application/x-x509-key" instead.
> After checking the tika-mimetype.xml and comparing it to my .p12 file I found 
> the following MIME magic which explains why I got these types back.
> {code:xml}
> 
>     
>     
>     
>     
>     
>    

[jira] [Commented] (TIKA-3784) Detector returns "application/x-x509-key" when scanning a .p12 file

2024-02-12 Thread Tim Allison (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-3784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816827#comment-17816827
 ] 

Tim Allison commented on TIKA-3784:
---

Well, sure, if you want to make it easy! Y, let's go with something like that!

I'll see what I can do tomorrow. Thank you!

> Detector returns "application/x-x509-key" when scanning a .p12 file
> ---
>
> Key: TIKA-3784
> URL: https://issues.apache.org/jira/browse/TIKA-3784
> Project: Tika
>  Issue Type: Bug
>  Components: detector
>Affects Versions: 1.26
>Reporter: Matthias Hofbauer
>Priority: Critical
> Attachments: dump_p12s.txt
>
>
> We are using tika to check if the MIME type of the file extensions matches 
> with the MIME type of the file content.
> After our upgrade from tika-core 1.22 to 1.26 our logic does not work anymore 
> for certificates of type .p12, .pfx, .cer, .der.
> For the .p12 and .pfx extension the MIME type is "application/x-pkcs12" but 
> the tika detector returns "application/x-x509-key" instead.
> After checking the tika-mimetype.xml and comparing it to my .p12 file I found 
> the following MIME magic which explains why I got these types back.
> {code:xml}
> 
>     
>     
>     
>     
>     
>                      mask="0x00FC" offset="0"/>
>                      mask="0xFC" offset="0"/>
>     
>  {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (TIKA-3784) Detector returns "application/x-x509-key" when scanning a .p12 file

2024-02-13 Thread Lonzak (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-3784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816896#comment-17816896
 ] 

Lonzak commented on TIKA-3784:
--

One other possibility would be to combine both approaches:

Usage of the current one which is quite fast to pre-categorize a file type. 
Then if it is a security related file type then use the keystore method of Java 
or BC to do the final determination...

> Detector returns "application/x-x509-key" when scanning a .p12 file
> ---
>
> Key: TIKA-3784
> URL: https://issues.apache.org/jira/browse/TIKA-3784
> Project: Tika
>  Issue Type: Bug
>  Components: detector
>Affects Versions: 1.26
>Reporter: Matthias Hofbauer
>Priority: Critical
> Attachments: dump_p12s.txt
>
>
> We are using tika to check if the MIME type of the file extensions matches 
> with the MIME type of the file content.
> After our upgrade from tika-core 1.22 to 1.26 our logic does not work anymore 
> for certificates of type .p12, .pfx, .cer, .der.
> For the .p12 and .pfx extension the MIME type is "application/x-pkcs12" but 
> the tika detector returns "application/x-x509-key" instead.
> After checking the tika-mimetype.xml and comparing it to my .p12 file I found 
> the following MIME magic which explains why I got these types back.
> {code:xml}
> 
>     
>     
>     
>     
>     
>                      mask="0x00FC" offset="0"/>
>                      mask="0xFC" offset="0"/>
>     
>  {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)