I'm working on code using XPC for inter-process communication. Sharing the code on GitHub will expose the .entitlements file, containing my team identifier.
Now will this be a security risk in any way?
Other developers could use the team identifier but won't be able to sign apps. So I expect everythings okay as long as I sandbox and sign my apps and helpers. What do you know about this?
It probably won't be a huge security risk, however to be sure and to keep your git repository clean I suggest adding it to your gitignore file. There is no reason why you would need to share your .entitlements file.
Related
We have a static website, we outsource the website maintenance, we don't have source code repository, so contractor edits the code on production server directly.
It has no problem, as our website built decades ago with old school html4 only. What it store on the web server, is what the source code is.
At today, the web site can be composed by UI framework, eg. Vue, React....etc. Sometimes the HTML file contains web components and other JS module. I have done a little google to learn that, building a website today need NPM, NodeJs, Webpack, Gulp....etc, they manage js module and bundle / built the production code...
My problem is, we like to revamp our website with modern UI (HTML5, CSS3, mobile friendly...). The tools I just mentioned will "process" the source code and output production code. We don't have the source code server (eg. git server), for our contractor to store the source code. ( our company management doesn't allow us to purchase private repository services on the internet. eg..github, gitlab...etc).
Can I keep using the old school way? the source code on the production web server is always the only source code...
I have tried myself to using the require.js, it loads js module on the browser, so I can handle module loading without node.js and Webpack, and writing the web component in vanilla js. Is it the only solution I can do?
You certainly could continue to manage this site the "old school" way, but in doing so, you'll be ignoring the benefits that all the modern tools give you.
For example
no git (or other version control) means no rolling back changes (or errors)
using version control software also means you have a backup and you don't need to set up a backup scheme on the production server to save your files
editing on the production server means if someone makes a typo, the site is messed up; etc.
I would strongly recommend modern tools; if cost is a concern, consider free tools:
Bitbucket has long offered free private repositories; Github has recently also started offering them.
Tools such as Hugo, Jekyll, and others permit creation of static sites quickly and easily.
Edit in answer to some of the comments...
Switching to a more modern development workflow (including version control) is not just about saving money, it's also about:
Does the employer/client want their developer(s) spending a lot of time managing the site - possibly including fixing problems - or do they want them working on something else?
Is the employer/client willing to have periods of time when the site does not work correctly? As #birdspider mentions in the comments above, if you have multiple people working on the website on the production server, they're going to be messing up each others' work. Note that the use of a VCS helps avoid avoid some of the problems with people stepping on each others' toes and it also make fixing those conflicts so much easier.
If you approach the employer/client with these points and their answer is "we just don't like it", then there's probably not much else you can do. If I were in your shoes, I'd be strongly tempted to either a) implement something on my own (just to preserve my own sanity, although really this is probably not a good idea) or b) find a new job.
I am developing opensouce project with a huge pile of dependencies, and I find Puppet a perfect tool for my requirements.
However, my target audience is not necessarily experienced with Puppet. To the point they may not be even know how web servers work. So I would like to ask the user to “run this in terminal” for the simplest case, but if the user also wants to configure some parts of my software, he would have to learn puppet. And educating them Puppet defeats the “servers for dummies” purpose of my project.
Basically, dare I say, I need Unity from the deployment world.
The thing I came up with, is to use ‘json’ as a backend for Puppet, and then write some GUI tool that would generate/modify that json using JSON Schema. Of couse, this thing will be optional and experient Puppet usets could still just use my module as is.
The questiond is, am I doing it right? Is there a solution for my problem?
Thanks in advance.
You can use Hieradata to give the ability to users to configure some parts for your "Software". you can put your hiera configuration in a git repository or build a tool to edit & update this hiera configuration.
There is some tools that you can use in order to make more easier for your users like Foreman and Puppetboard
But I think it's mandatory for your users to have a basic knowledge of Puppet so they can debug or manipulate the software.
These are some things that you can use.
Have a look at these:-
https://puphpet.com/
https://github.com/voxpupuli/puppetboard
I'm a complete Node noob, so I apologize if this question has an obvious answer.
I'm looking to create a web app that will run plugins from untrusted sources (i.e. community submissions). So I need to lock down those plugins into a sandbox where only certain access is allowed (can't write to disk, etc.). Ideally, the plugin would only be able to use certain approved node packages and APIs.
Is this possible in Node? If so, can you point me toward a package or documentation that will get me started?
Here is a small list of projects that can help you:
https://github.com/gf3/sandbox
https://github.com/hflw/node-sandbox
https://github.com/bcoe/sandcastle
https://github.com/wearefractal/boxy
I suggest the first one (sandbox) since it's more mature.
I would also contribute to the list with my library: https://github.com/asvd/jailed. In addition to the sandboxing of the untrusted code (in a restricted subprocess), it gives an opportunity to export any set of functions inside the sandbox thus defining a custom API for the sandboxed code.
There are several Custom Security Tests have been created and deployed. It is no issue in one Worklight project to consume the customSecurityTest. But when other Worklight project also try to consume the same customSecurityTest. Got 401 Unauthorized error. The response on client side looks like /*-secure-
{"challenge.s":{"wl_antiXSRFRealm":{"WL-Instance-Id":"guhao08ggi00es5ec9r2mfshp3"}}}*/.
If the customSecurityTest could not be reused, it will defeat the whole purpose of reuse the security framework. Please help to solve it. Thanks!
Jerry
If you have two separate projects, you'll need to copy your securityTests.
There is no sharing (at large) between projects.
If you have two applications of the same project, you could use the same securityTests in both.
I have to say that this limitation is not any defeat of the security framework's purpose...
I want to build a Chrome Extension for the Developer Tools that watches for changes a given folder and refreshes/updates the CSS/JS/image files in the browser.
There is a similar approach already:
http://tin.cr
Tin.cr uses NPAPI which is not sandboxed and has some security issues, so I can't use it in some dev environments where company polices have strict rules (specially in the financial industry).
Another approach is to use NaCl (Chrome's Native Client, which is sandboxed).
I am a front-end dev, with little knowledge in C, so I need some help, please.
How can I watch/monitor file changes in libuv? If someone could provide a code snippet I would greatly appreciate it.
From what I understand from the docs, libuv would allow the extension to work cross-platform, am I wrong?
Thanks
NaCl doesn't have an API to watch changes in a given folder on disk. Can you use Google Drive? Google Drive has an API for getting list of changed files: https://developers.google.com/drive/v2/reference/changes/list.