I am creating an api for modifying X509 certificates in C and I want to add a way to modify an extension. For example, add another DNS entry to subjectNameAlt so that it would be DNS:example.com,DNS:example2.com instead of just DNS:example.com . The reason that deleting and re-adding is bad is because I then have to reparse the extension (which is difficult) and I would rather just add a piece of information. How would I do this via the OpenSSL API?
I tried to simply reuse the add code:
ex = X509V3_EXT_conf_nid(NULL, &ctx, NID_subject_alt_name, "DNS:new.dns.example");
if (!ex)
return;
X509_add_ext(cert,ex,-1);
X509_EXTENSION_free(ex);
But after running that, the extension isnt found at all (even if i try to add another new one).
Have a look at
demos/x509/mkcert.c
demos/x509/selfsign.c
demos/x509/mkreq.c
in your openssl distribution. I suspect that you are not setting up your context; or you are making an assumption in that some i2d/etc is called behind the scene when you say 'is not found at all'. Note that X509_sign() and their ilk do create a lot of this. If you are not calling anything -then do not expect any of those to be created.
Related
I am working on an UWP text editor. I have added desktop extension to it to modify system files and other read only files. The problem I have is there is no reliable way to detect if a file has read-only attribute. FileInfo.IsReadOnly doesn't work and StorageFile.Attributes has FileAttributes.ReadOnly when file is dragged and dropped from file explorer.
How do I reliably check whether the file has read only flag or not?
While there is no way to detect the readonly attribute by using dotnet methods, however GetFileAttributesExFromApp can be used to get a lot of attributes(readonly, hidden etc.) of the file that aren't available via StorageFile api. Also, SetFileAttributesFromApp can be used to change/remove these attributes.
Edit
After some research and deep dive in MSDN, I came to know about RetrievePropertiesAsync(IEnumerable<String>) and
SavePropertiesAsync(IEnumerable<KeyValuePair<String,Object>>) methods for Windows.Storage.FileProperties.StorageItemContentProperties which can be used to get and set properties by name (Full list of properties names), the name System.FileAttributes can be used to get file attributes and can be used to detect if read-only flag is present. While retrieving properties always works modifying properties will only work if app has write access to file (Windows.Storage.StorageFile.Attributes doesn't contain ReadOnly flag), although SetFileAttributesFromApp works for that scenario but limitation of SetFileAttributesFromApp is it won't work for sensitive file types (.bat, .cmd etc.). So both those methods could be used combined to have maximum effect.
You can see the Attributes property has ReadOnly or not.
var filePicker = new Windows.Storage.Pickers.FileOpenPicker();
filePicker.ViewMode = Windows.Storage.Pickers.PickerViewMode.Thumbnail;
filePicker.SuggestedStartLocation = Windows.Storage.Pickers.PickerLocationId.VideosLibrary;
foreach (string format in HelperUP.subtitlesFormat)
filePicker.FileTypeFilter.Add(format);
var file = await filePicker.PickSingleFileAsync();
if (file == null)
return;
Debug.WriteLine(file.Attributes);
The reason FileAttributes.ReadOnly throws an exception is that the System.IO APIs don't have access to arbitrary file locations on the hard drive in UWP.
On the other hand, a StorageFile opened in the app via drag & drop has this attribute set too, which is a problem that is continuously being discussed and hopefully will be fixed in a future version.
The only workaround I can think of (apart from always using the desktop extension) is declaring the broadFileSystemAccess capability (I have described the process here for example). This is a capability which gives you access to the whole filesystem and allows you to get a file using an arbitrary path with the StorageFile.GetFileFromPathAsync method (see Docs). Please note you will need to explain why this capability is required when you submit the application to the Microsoft Store.
With broad filesystem access, you could take the drag & drop StorageFile, take its Path and retrieve the same file again using StorageFile.GetFileFromPathAsync. This new copy of the file will no longer have the "false-positive" Read Only attribute and will reflect the actual attribute state from the filesystem.
Im trying to use Microsoft.Office.Interop.Word._Document.Close() in a .net 3.5 windows form app.
No matter how much I search here and on Google I cannot find the correct parameters to put in the Close method.
I am using version 14.0.0.0 of Microsoft.Office.Interop.Word and I would like to close the document without saving and ideally ensure that the application can isolate the document thread so that users can still open word documents outside the running application.
See the Close method of the Document class described in MSDN. If you need to omit the parameter and use the default value - pass the Type.Missing parameter.
Try this:
object doNotSaveChanges = Word.WdSaveOptions.wdDoNotSaveChanges;
object missing = System.Reflection.Missing.Value;
_Document.Close(ref doNotSaveChanges, ref missing, ref missing);
This is the source
I'm not sure if you'll need the middle line or not. It's not from the original source it's from here
I have implemented a generic blob serving handler as mentioned in the appengine docs. The handler will serve any blob to you, as long as you know that blob's key string. I am using it to easily compose URLs that clients can use to download their files. If client A inspects the URL to download their file and finds their blob key (i.e. 1CX2kh468IDYKGcDUiq5c69u8BRXBtKBYcIaJkmSbSa4QY096gGVaYCZJjGZUpDz == str(BlobKey)), can they somehow reverse-engineer this key and easily construct another key that can be used to download client B's files? Or does the key have a random component added?
For reference, there is this note about str(db.Key), which is what raises my question:
Note: The string representation of a key looks cryptic, but is not
encrypted! It can be converted back to the raw key data, both kind and
identifier. If you don't want to expose this data to your users (and
allow them to easily guess other entities' keys), then encrypt these
strings or use something else.
I am creating the files like this, which does not specify a filename parameter, so I think the question boils down to, how does create() "pick" a filename when one is not specified? I suppose I could generate a random filename and pass it in here to be doubly sure this is secure.
file_name = files.blobstore.create(mime_type='application/octet-stream')
BlobKeys are non guessable. If a user has one key, that in no way enables them to guess another key. Unlike datastore keys, which contain full path information, BlobKeys do not encode any such data. You can share them safely without risk of a user doing an attack as you describe.
(I could not locate docs for these claims - this is based on my recollection.)
Assign a filename when creating a blob:
name = .....
file_name = files.blobstore.create(mime_type='application/octet-stream', _blobinfo_uploaded_filename=name)
And you do not need to use str(BlobKey). The BlobKey can be part of your serving url
I'm going through Lift's basics in Section 3.2 SiteMap of Simply Lift and one thing struck me.
Using the default SiteMap code, you can ask for, say, info view in three ways:
GET /info,
GET /info.html,
GET /info.xml (why?).
What is more, you can request index view in four different ways:
GET /,
GET /index,
GET /index.html,
GET /index.xml.
How can I limit this behaviour to GET / for directories and GET /info for files?
P.S. All of these return 200 OK:
foursquare.com/,
foursquare.com/index,
foursquare.com/index.html,
foursquare.com/index.xml.
Shouldn't one resource have one URL only?
There are actually more than four ways that it can be parsed. The full list of known suffixes (any of which can be used to access the page) can be found here.
I think the reason for that is that lift can be used to serve any resource, so most are explicitly added by default.
I think you could disable Lift's processing of all extensions by adding this to Boot.scala:
LiftRules.explicitlyParsedSuffixes = Nil
However, I wouldn't recommend that as there may be some side-effects.
Using Req with RestHelper you can specify the suffix explicitly, but I don't know if there is such a construct to do so with Sitemap.
Actually, the code to determine whether Lift should handle the request or not is here. You can see the default extensions in the liftHandled method directly above, but they can all be overridden with LiftRules.liftRequest. Something like:
LiftRules.liftRequest append {
case r => Full(r.path.suffix.trim == "")
}
Should do the trick.
As far as why it works that way, Jason is right that Lift is designed to handle multiple types of dynamic resource.
How do you allow a C-extension to use rb_f_require to require a file from outside the ext directory (e.g. requiring lib/foo/foo.rb from ext/foo.so).
Not really sure why this isn't converted into html like the rest of the ruby hacking guide that had been translated, but perhaps some portion of this would be helpful?
http://rhg.rubyforge.org/svn/en/chapter18.txt
Given that rb_f_require appears to do a normal load path search, it would seem it would search out into lib/foo if that is in the search path. However, if you are looking for another foo.rb I would imagine you would have name problems if foo.so appears first. Perhaps using a different name for foo.rb could solve the problem?