I don’t know - personally I don’t like the idea of just running a program and
hoping it doesn’t do anything malicious. By using a tool like this, you’re
basically running the system unprotected for some period of time, to find out
what permissions are needed.
When I was writing the
It's disapointing where we have ended up, if you look back to 2010 we made
amazing progress and our committers worked together.
I could produce another release artifact, but only if that's what the community
wants.
I'd like to hear from people what they want from this project?
Regards,
Greg, the message I got from you previously was you wanted tools to make life
easier for new develooers, that you weren't concerned about security as your
code ran behind the firewall on local networks?
I'm trying to find common ground with you, to salvage what's left of the
project.
It would
We should perhaps raise some of the development problems we're having with the
board.
I can create another release artifact in the near future, I need to look into
how to create binary artifacts and stage the maven artifacts.
Regards,
Peter.
Sent from my Samsung device.
Include original
I agree with trunk -> river 3.0 being an improvement, although I would like to
make mention in the release notes, that statemements about security are
outdated and should not be relied upon.
My comment about development issues relate to how we as developers are
functioning as a community /
Remember we are an open source organization. Getting source releases out
is the main thing. Binary artifacts are an optional extra.
Can you state your concerns with making the Trunk River 3.0? Do you feel
it is a regression relative to our current release? My impression is
that it is better,
Example of security policy generation. In this case I didn't have
aliases for the JCE provider certs, but you get the picture, you'll not
it also includes whatever Principals your code is running with.
You run your program, use each process and the permission required will
be generated into
