Xades4j signature verification - xades4j

XAdES4j documentation says that
XAdES4j can verify signatures in any of the four main XAdES forms.
Does that mean that it verifies XAdES BES, EPES, T and C (and does not verify X, XL and A)?

Yes, that's correct. The support for extended forms is not completed. There's some work on the issue tracker by a contributing developer that adds support for extended forms, but it hasn't been possible to go through that work yet.

Related

What is __CUDANVVM__ for?

The macros __CUDACC__, __CUDANVVM__, and __CUDA_ARCH__ are used in many places in the CUDA library header files. I am able to find info on __CUDACC__ and __CUDA_ARCH__, but I don't get anything on Google regarding __CUDANVVM__ other than finding it used in the headers. Due to the usage for static/forced-inline of calls through to functions of the form __nv_<base_function_name>, my intuition is that it is used as part of the process of compiling with libdevice and those __nv_* functions are the device-optimized bitcode versions of the functions they correspond to, but I'm not yet sure and so was looking for clarification.
Going by http://docs.nvidia.com/cuda/libdevice-users-guide/function-desc.html#function-desc, it appears that the __nv_* functions are indeed those from libdevice, so it seems my hunch was correct.

Does SAP ABAP offer a way to sign assemblies?

I'm trying to find out whether it is possible to sign binaries written for SAP systems in ABAP. Contextually does it make sense? I've only found some reference to an add-on assembly kit which seems to be some sort of packaging standard. Can this be used to authenticate the source and integrity of ABAP modules?
Greatly appreciate your feedback~!
I seem to have found an answer to my question somewhat...one forum discussion states that ABAP is only interpreted and that there are no binaries to sign in the first place. I'm a bit confused though as to what the Add-on Assembly Kit is. I suppose it's a way of packaging the ABAP code into a certifiable package, which I suppose is the closest we'll get to what I'm looking for-although I'm not sure how this works if you're not interested in sharing the package with SAP for certification...If you have any insights please enlighten me.
Thanks!
not positive of your end requirement but I'll answer the best I can. ABAP is interpreted so there really is no need to sign a binary as there is none to sign. Because third party's needed ways to deliver solutions or code to their customers in a packaged manner SAP developed the add-on assembly toolkit, (emphasis on assembly) this allows the third party a tool to package all the solution pieces,( classes, tables, includes, screens etc.) into an add-on that can be installed, versioned etc. in your customers SAP system. So it's main purpose is to allow you to assemble the myriad pieces that make up your solution.
Of course if your talking about a single app, report etc. this obviously would be overkill.
If what you are seeking is a way to know that an app comes from your specific company, then you can request a custom namespace, when you get one assigned they issue you a key which only your company uses to install the namespace and that sort of works like signing, your programs will all exist in your namespace and be identified as such.
I'm sure there are more details others can provide but that should get you started.
Later.....

What is the difference between binary and source compatibility conceptually ?

In the context of webkit in chromium source code ,it says it is source compatible but not binary compatible. Does it suggest that we build .dll file of webkit and build it with chrome binary ?
(This answer doesn't talk about the specific context of WebKit - it's not clear what exactly you mean by the various "it says" parts. I've tried to give a more general answer.)
Suppose we have a library called LibFoo, and you have built an application called SuperBar which uses LibFoo v1.
Now LibFoo v1.1 comes out.
If this is binary compatible, then you should be able to just drop in the new binary, and SuperBar will work using the new code without any other changes
If this is only source compatible then you need to rebuild SuperBar against v1.1 before you'll be able to use it
I would think of it from the point of view of Linking
Linking is the process of taking a class or interface and combining it into the run-time state of the Java Virtual Machine so that it can be executed.
Linking a class or interface involves verifying and preparing that
class or interface, its direct superclass, its direct superinterfaces,
and its element type (if it is an array type), if necessary.
If introducing a new change breaks the linking, then it is not source (code) compatible (as well as binary compatible)
If introducing a new change does not break the linking, then it is at least binary compatible

Do any "major" frameworks make use of monkey-patching/open classes

I am curious about the usage of the feature known as open classes or monkey-patching in languages like e.g. Ruby, Python, Groovy etc. This feature allows you to make modifications (like adding or replacing methods) to existing classes or objects at runtime.
Does anyone know if major frameworks (such as Rails/Grails/Zope) make (extensive) use of this opportunity in order to provide services to the developer? If so, please provide examples.
Rails does this to a (IMHO) ridiculous extent.
.Net allows it via extension methods.
Linq, specifically, relies heavily on extension methods monkey-patched onto the IEnumerable interface.
An example of its use on the Java platform (since you mentioned Groovy) is load-time weaving with something like AspectJ and JVM instrumentation. In this particular case, however, you have the option of using compile-time weaving instead. Interestingly, one of my recent SO questions was related to problems with using this load-time weaving, with some recommending compile-time as the only reliable option.
An example of AspectJ using load-time (run-time) weaving to provide a helpful service to the developer can be Spring's #Configuration annotation which allows you to use Dependency Injection on object not instantiated by Spring's BeanFactory.
You specifically mentioned modifying the method (or how it works), and an example of that being used is an aspect which intercepts am http request before being sent to the handler (either some Controller method or doPost, etc) and checking to see if the user is authorized to access that resource. Your aspect could then decide to return – prematurely – a response with a redirect to login. While not modifying the contents of the method per se, you are still modifying the way the method works my changing the return value it would otherwise give.

What are some different ways of implementing a plugin system?

I'm not looking so much for language-specific answers, just general models for implementing a plugin system (if you want to know, I'm using Python). I have my own idea (register callbacks, and that's about it), but I know others exist. What's normally used, and what else is reasonable?
What do you mean by a plugin system? Does Dependency Injection and IOC containers sounds like a good solution?
I mean, uh, well, a way to insert functionality into the base program without altering it. I didn't intend to define it when I set out. Dependency Injection doesn't look particularly suitable for what I'm doing, but I don't know much about them.
A simple plugin architecture can define a plugin interface with all the methods the plugin ought to implement. The plugin handles event from the application, and can use the application's standard code, model objects, etc. to get things done. Basically the same as an ASP.NET Form does, except that you're overriding rather than implementing.
Nobody taught me this part, and I'm no expert, but I feel: In general a plugin will be less stable than its application, so the application should always be in control and only give the plugin periodic opportunities to act. If a plugin can register an Observer, then calls to the delegate should be tried/caught.
There is a very good episode of Software Engineering Radio, which you may be interested in.
For future reference, I have reproduced here the "Rules for Enablers" (alternative link) given in the excellent Contributing to Eclipse by Erich Gamma, Kent Beck.
Invitation Rule - Whenever possible, let others contribute to your contributions.
Lazy Loading Rule - Contributions are only loaded when they are needed.
Safe Platform Rule - As the provider of an extension point, you must protect yourself against misbehavior on the part of extenders.
Fair Play Rule - All clients play by the same rules, even me.
Explicit Extension Rule - Declare explicitly where a platform can be extended.
Diversity Rule - Extension points accept multiple extensions.
Good Fences Rule - When passing control outside your code, protect yourself.
Explicit API Rule - separate the API from internals.
Stability Rule - Once you invite someone to contribute, don?t change the rules.
Defensive API Rule - Reveal only the API in which you are confident, but be prepared to reveal more API as clients ask for it.
In Python you can use the entry-point system provided by setuptools and pkg_resources. Each entry point should be a function that returns information about the plugin -- name, author, setup and teardown functions, etc.
How about abstract factory? Your base program defines how the abstract concepts interact with each other, but the caller has to provide the implementation.