I am working on an application that is used to sign/verify files according to pkcs7. I am using bouncycastle. The problem is that whenever i pass in (to verify!) a file containing a signature i cannot find a way to distinguish whether the file contains both signature and signed data or just a signature. The point is to ask the user to select a second file if the first one contains only signature /and display appropriate error/.
Is there any way around this problem?
To construct the CMSSignedData (the first time, before you know whether it has encapsulated content), just use the CMSSignedData(byte[]) constructor, where byte[] is the full contents of the file.
Once you have the CMSSignedData instance, then getSignedContent() simply returns null if the content was not encapsulated.
Once you have the basics working, if you are dealing with very large files, you may want to look at CMSSignedDataParser as a more advanced option that will avoid reading in the entire file.
Related
I am trying to create a unique id and attach it to a LabVIEW file so that later I can read back that id and know I am looking at exactly the same file. I must be able to generate the id and read it back programmatically. The information must be hidden from the user accessing the file and persist across operating systems and storage mediums.
I was thinking of just adding it into the file 'comment' section, but it appears the Windows no longer supports file comments.
Any ideas?
I would suggest using the Set Tag method on the VI (with persistence) and saving multiple copies of the VI using the Save Instrument method, where each copy would then have its own unique value of the tag. Note that the method is defined as a scripting method, so you would probably need to enable scripting in the LV options to access it.
I don't think there's any API for enumerating tags, so there would be no way to find the value unless you know what the tag is called. Obviously, it's encoded somewhere in the VI file itself, and presumably it would be possible to extract a list of tags if you know the structure of the file, but that's not knowledge I would expect most students to have.
I'm not sure if you can call the set tag method from Python using an external connection to VI server, but certainly the LV code for this should be pretty simple - basically a for loop with ID generation, a couple of method calls and saving a CSV file so you can keep track of which ID belongs to which student. If you use existing IDs, you don't even need to generate and save the IDs.
Currently I'm developing a minimalist ZIP 2.0 library.
In keeping with the motto "Read the f*ckin' manual!", I read PKWARE's appnote, so I know a ZIP archive containing only the "end of central directory record" is considered empty. This record defines a variable size "archive comment" in the end, which is why one has to scan backwards in search for the signature "PK\5\6" when loading the central directory. This leaves me with two questions:
1) What should I do when the user tries to add an archive comment containing this sequence?
2) Is an empty archive allowed to have a comment? (WinRAR isn't able to show it when the archive is empty while 7-Zip is)
UPDATE:
I have had email contact with Mr Roshal, lead developer of WinRAR. He confirmed 2) to be a bug in WinRAR that is now fixed.
The ZIP file format does not specify what is valid for the content of a file comment or zipfile comment. In one place their documentation describes the comment as "text information", but elsewhere, the comment is described as "bytes of data", and the appnote itself doesn't say anything about what can go in a comment.
However, even if the spec does allow arbitrary binary data in a comment, that doesn't mean that you have to allow it using your library, and if you choose to allow it, that doesn't mean you have to make it easy.
So, here's a list of possible ways of handling the comment. Choose one.
Refuse to allow binary data in comments.
Allow binary data, but refuse to allow the specific signature.
Allow arbitrary binary data, but require the user to provide some sort of extra confirmation, if they try to include the signature.
Allow arbitrary binary data, don't worry about the signature.
Of course, for any option where imbedding the signature is possible, the documentation should warn the user that doing this will result in an invalid ZIP file.
Background:
I have an application to which I want to pass a param at download time, which is actually the id of the advertiser from which it got downloaded. We use this id to report successful installation.
This param will be different for different advertisers. Somebody suggested me here to append the param data at the end of the exe and fetch it. I was able to do so perfectly.
Problem:
The problem now is that if we append in the exe, it breaks the digital signature of exe. If I replace the data with same amount of other data, the digital signature tab remains, but the digital signature becomes invalid.
So is there any way to append/replace data in exe without bothering its digital signature?
It doesn't sound too achievable, maybe make the download a zip with the signed exe and a text file with the code (which it then reads).
Bit of a wild stab in the dark would be to try using NTFS Alternate Data Streams
This may or may not invalidate the signature
You may or may not be able to configure mime types such that the exe could be a single download.
The additional data may or may not be preserved when a file is zipped.
In cases when two attachments with the same filename are attached to a Notes Document, the second file is renamed internally to something like ATTXXXX. Even if the first filename is deleted and document re-saved, the internal filename remains cryptic.
There doesn't seem to be any way to retrieve the original Filename through back-end functions. I have looked high and low in LS but also in the C++ API, and could find nothing. It seems to be a trick that can only be done in the front-end. I am not sure where the information in the file icon graphic is stored, and whether it is accessible. In simple cases it would be possible to do a rename, I suppose (i.e. there is a single attachment and a single file icon graphic).
Could anybody confirm that this is, indeed a limitation of Notes or is there a cool way to solve this?
This is causing me some headaches whilst processing a large number of documents. My customer has trouble believing that there are some things that can only be done in the front end.
You should be able to get the original filename, even with duplicates.
It is not when the file is attached that the name is changed, it is when you detatch it.
You are probably using the .Name property, try the .Source property of the EmbeddedObject, that should return the original filename.
From the help:
If the NotesEmbeddedObject is an embedded object or object link, this property returns the internal name that Notes uses to refer to the source document.
If the NotesEmbeddedObject is a file attachment, this property returns the file name of the original file.
Syntax
To get: source$ = notesEmbeddedObject.Source
It's in the CD records for the rich text -- you will see it if you use NotesPeek to examine the contents of the rich text item. But I don't think it's accessible through the NotesRichText navigator class, so I'm pretty sure you would have to go the C API and parse through the CD records. Or, the MIDAS Rich Text API can probably get it, but that's third party software. I.e., not free.
Imagine an environment in which users can upload images to a website by either uploading it from their pc or referring to a remote url.
As part of some security checks I'd like to make sure that the referenced object is indeed an image.
In the case of a remote-url, I of course check the content-type, but this isn't bullet-proof.
I figured I could use ImageMagick to do the task. Perhaps executing the ImageMagick.identify() method and if no error is returned and returned type is either JPG|GIF|,etc. the content is an image. (In a quick check I noticed that TXT files are identified correctly as well, so I have to blacklist these)
Is there any better way in doing this?
You could probably simply load the image via ImageMagick's appropriate function for your language of choice. If the image isn't formatted properly (in terms of internal formatting, not its aesthetic properties, that is), I would expect ImageMagick to refuse to load it and report an error. In PHP, for example, readImage returns false if the image fails to load.
Alternatively, you could read the first few hundred bytes of the file and determine if the expected image file format headers are present; e.g., "GIF89" etc.
These checks may backfire, if your image is in a compressable format (PNG, GIF) and it is constructed in a way similar to a zip bomb https://en.wikipedia.org/wiki/Zip_bomb
Some examples at ftp://ftp.aerasec.de/pub/advisories/decompressionbombs/pictures/ (nothing special about that site, I just googled decompression bombs)
Another related issue is that formats like SVG are in fact XML and some image processing tools are prone to a variant of "billion laughs" attack https://en.wikipedia.org/wiki/Billion_laughs
You should not store the original file. The generally recommended approach is to always re-process the image and convert it to an entirely new file. There have been vulnerabilites exploited inside valid image files (see GIFAR), so checking for this would have been useless.
Never expose your visitors to an image file that you have not written out yourself and for which you did not choose the file name yourself.