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.
Related
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.
I'm looking for a way to embed file attachments (like screenshots) inside a Perforce changelist. I'm hoping (but not optimistic) that there's a way inside P4 to actually do this, possibly via a plugin.
If not, I'll either have to look into writing a plugin myself (any pointers?), or I have to cook up a wrapper for P4 checkins that also uploads/submits the attachment, then links that attachment to the CL via an identifier inside the CL. (And then I need a tool to correlate and display both).
To add a bit more information: I'm interfacing with the P4 server via a P4API bot that I'm writing. That bots crawls over every checkin and harvests the data it gets to generate reports. I.e. it correlates submissions with the actual feature spec that informed the task, generates a history of progress for that task etc. Within that context, attaching additional meta data to a CL (like a screenshot) is useful because those attachments can then be used in the data mining - they can enhance the reports that I'm generating.
I can guard against bad/rampant metadata attachments via a wrapper program that is used to make 95% of all our P4 submissions, anyway (it has its own dialog). But I gotta figure out how to present all the data inside P4 when the P4 CL spec only seems to have text available.
I don't think there is any (easy) way to do what you're requesting. A changelist is "an atomic change transaction". There is very little meta-data with them. The P4 command reference for p4 change lists everything you're allowed to do, and adding an arbitrary attachment isn't there.
You could always open a feature request in the Perforce forums.
In Response to Edits
It looks like this is actually just one instance of a larger problem you're facing: managing meta-data around your depot's projects and its changelists. I would suggest you use this requirement as a driving force behind making some larger process changes at your organization. If you have a lot of data being generated based on automated analysis of your projects, it would be better to create a proper database to organize it all. Your submission wrapper could handle putting screenshots (or any other meta data) in a database and annotating the change list description with tags that indicate where to find attachments in the database.
A comprehensive database solution would allow you to associate attachments, changelists and other data with each other and other project resources in a more organized fashion than you currently have.
Original Response
If you decide to write a plugin to handle just this task without a database, my suggested approach would be the following:
Designate a shared network drive or directory that is accessible to all team members as the "perforce attachment dump". Users should have write access to this area.
Use the changelist description field to create a tag to name a file that should be attached. For example, "Attach: file_name.jpg".
Your users use the plugin to navigate to the file(s) locally and the plugin will copy it to the dump drive and add the tag to the description. The plugin should enforce some naming scheme to make the files easy to find. Perhaps append the changelist number to the file base name? Or create a folder for each changelist?
Use a server side pre-submit trigger and script to scan submitted changelist descriptions for tags and retrieve this file from the attachment dump. It should probably reject changelists with the tag if it can't find the file.
The server side script should move the file to a share drive that is read-only to users. This is so that if you want to look at an attachment for a changelist that is five months old, you can be sure it will still be available.
Give your plugin the ability to open the attachments on the read-only share drive from your developer's local machines, from within P4 and P4V.
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.
Not much to add to the question. How does rsync filter which data it must transfer and which it can leave alone?
Directly from the man page (http://linux.die.net/man/1/rsync):
"Rsync finds files that need to be transferred using a "quick check" algorithm (by default) that looks for files that have changed in size or in last-modified time. Any changes in the other preserved attributes (as requested by options) are made on the destination file directly when the quick check indicates that the file's data does not need to be updated."
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.