According to this page:
No central approval process for adding packages. When you upload a package to the NuGet Package Gallery (which doesn’t exist yet), you won’t have to wait around for days or weeks waiting for someone to review it and approve it. Instead, we’ll rely on the community to moderate and police itself when it comes to the feed. This is in the spirit of how CodePlex.com and RubyGems.org work.
This makes me feel uneasy. Before I download a Firefox add-on, I know it should not contain malicious code, because AFAIK all add-ons on addons.mozilla.org are reviewed by Mozilla. Before I download a open source project from codeplex.com or code.google.com, I know it should be safe because anyone can check it's source code. And I can also use WOT (web of trust) to check how other people think about the project.
But before I download a package from NuGet official package source. Take this one for example. I do no know who made this package, nor what is contained in the package. It seems to me that anyone can pack anything into a package, give it any name they want (like "Microsoft Prism", as long as the name is not taken), then upload it to the official package source.
Should I be worried about the safety of the packages on NuGet official package source?
Your uneasyness should apply to software you obtain from any source:
Binaries downloaded from Sourceforge.net, Codeplex.com, etc could feasibly contain malicious code (either planted by the original submitter or, more likely, inserted by a hacker into the website) that may pass unnoticed until someone (you?) gets bitten and raises the alarm.
Even if you compile your own binaries from source downloaded from one of the former websites, it could still perform malicious acts unless you go over all the source code and understand what it does.
Even software downloaded from 'app stores' (e.g. Apple iTunes, Android Market) could feasibly contain malicious code; some of these review processes are partially automated but are still not infallible, and the human review that also occurs is definitely not infallible!
There have been examples in the past of boxed software containing malware!
Perhaps there is a continuum of trust that you can have in software (delivered as binaries or source code), and something like the Nuget Package Gallery (and CodePlex.com and RubyGems, etc) probably lies on the less-trustworthy end of the continuum.
There are potential solutions to this sort of problem, such as those proposed by the Trusted Computing Platform Alliance, however they come with huge restrictions on the freedoms that we currently enjoy in developing software and sharing the software we develop as we see fit, without the need for licenses or cryptographic keys obtained from central authorities at great expense.
I believe that the community will come up with conventions and mechanisms for ensuring that Nuget becomes a trustworthy source of software libraries for .Net developers, whilst retaining the agility it has with not requiring a formal review process. However, the ultimate responsibility rests with yourself as a user to ensure that your IT security isn't compromised, and the precautions you take are a function of the criticality of IT security in the context of the software you are writing (e.g. home projects; probably low. Banking, medical, process control projects; probably high!)
NuGet doesn't manage trust. Even if it did, you would still have to be concerned about trusting what NuGet trusts.
You should absolutely be concerned about the safety of the code in a NuGet package. You should be concerned about the safety of any code you are not familiar with.
The approach I take to using packages, both personally and professionally, through NuGet and NPM are below:
Lock in the semantic version number completely. Explicitly specify the major, minor, and patch numbers. Don't assume that new updates will be safe or that their semantic version will be accurate.
Use only well known current versions for production.
Experiment with anything in a test environment with limited access e.g. under an account which isn't a local administrator, no local access to highly privileged credentials, no access rights to privileged resources granted to the test machine's IP.
Check the vendor. For example if the package is released by Amazon and it's an AWS SDK, then that package is probably safe to use if you trust Amazon.
For example the only packages I would trust right now to just go and add them in a production environment are Newtonsoft.Json and Nhibernate. My biggest concern with new open source packages that anyone can publish, is that they actually work as described before I buy-in and waste my time on something that doesn't meet my needs.
I feel as though if you did enough research on the package to see if it's suitable for a production environment, you probably have learned enough about the software and its community to determine if you can trust it's not doing anything maliciously. Researching the software and it's community really means more to me than NuGet's stamp of approval decided by one central authority that we all pray is perfect.
Related
We are using a Variscite VAR-SOM-AM33 platform for our project, and software platform is based on OpenEmbedded/Yocto.
To ensure the hardware is running with the current software, the devices are connected to the internet. So far, we have been following the OE recipes and generating ipk and applying software updates via opkg.
However, the process is not satisfactory as some of the recipes are poorly written (fails to uninstall/install during the upgrade process). What robust technique/solution are available for OE/Yocto based systems?
Thanks in advance.
I'd like to add SWUpdate to the list of packages that you should consider. It was recommended in a 2016 paper by the Konsulko Group for Automotive-Grade Linux. That paper mentions a few other options, and provides an analysis of the various tools, so it's probably worth a read. Quoting from the paper:
It is our recommendation that the reference AGL software update strategy make use of SWUpdate in a dual copy configuration and integrate OSTree support. This allows recovery from a corrupt partition for the exception case, but also optimizes the common case where small, incremental updates can be quickly applied or rolled back as needed to [meet] OEM policy.
I don't completely agree with the paper. For example, they wrote off Mender.io because it lacks community support, but IMO the Automotive-Grade Linux group is influential enough to create popularity from scratch. Still, it's a good paper, and the fact that they settled on SWUpdate was interesting to me. I was already leaning toward it because the author, sbabic, is involved in U-Boot software development, and we use U-Boot to burn new images into our device.
At the moment I'm unsatisfied with all of the current options, but mostly because I want extra functionality. I'll probably settle on a custom system which incorporates one or more of the aforementioned packages. Unfortunately that's not the kind of definitive answer that SO prefers, but I hope that it was helpful.
I'm working on a metadata layer to integrate the Software Updater (swupd) from Clear Linux with the Yocto Project / OpenEmbedded Core.
swupd performs whole of OS updates, rather than package-based updates, using binary deltas to only update the files which change and to do so in an efficient manner.
I recently wrote some documentation (within the docs/Guide.md file in the meta-swupd repo) about adopting the "Clear Linux Way" to utilise meta-swupd from an OE/YP based distro. A wikified version of that guide, including a link to the layer git repository, are available on the Yocto Project wiki:
https://wiki.yoctoproject.org/wiki/Meta-swupd
I also have a sample layer on Github which demonstrates use of the layer (this is also the distro layer I test much of meta-swupd with):
https://github.com/incandescant/meta-myhouse
About mender.io, I have recently talked to them regarding their open-source update.
Currently, they already have their client side developed, and is working on the server side. They use HTTP and JSON. This is their git, it is only supporting Beaglebone and QEMU at the moment.
The way mender.io works is: they will have one persistence data and uboot. and 2 rootfs (active and backup) to update. So, when there is an update on the server, the users will be notified to pull it down. Give a mender -rootfs image update command. And if the upgrade is success, the user gives another mender -commit command. If there is no mender -commit, the rootfs will be rolled back to the previous rootfs in the next reboot. Mender currently only support update of kernel and rootfs.
The main role of mender.io is to ensure that the mass distributed image upgrade process is recoverable from errors. In the Server side, mender.io developed a management server to the mass distributed devices using UUID.
Not to advertise but please try out mender.io and give feedback so that the software could be more mature.
Mender Introduction pdf
Well, you can either use package based upgrades, like you do. In that case, you'll need to test and verify everything locally before you push any updates to the field. Obviously, you'll likely need to improve a number of recipes. (And I assume that you upstream those immprovements, right?)
The alternative is to use image-based upgrades. Either with full images, see for instance the discussion at Stackoverflow: Embedded Linux mechanism for deloying firmware updates or swupd
Note: I got distracted while writing this answer, so look at the answer from joshuagi; he explains a lot more of swupd.
I think they are two problems here. We (OpenEmbedded) do need to be careful that we do not break package based updates.
Also, there are image updates like swupd (mentioned above and swupdate, described at: https://sbabic.github.io/swupdate/swupdate.html
meta-updater provides support for OSTree-based updates to OE systems.
OSTree is interesting because it provides a half-way house between full image updates (which are large and tricky to handle correctly) and package based updates (which are tricky to make robust). It has a 'git-like' object representation of a root filesystem, and uses chroot and hard links to atomically switch between file system images.
(Disclosure: I'm a contributor to meta-updater)
Posts here were done years ago. Now also RAUC seems to be promising alternative to mender.io
I would like to know what types of protection they are using with the Github Enterprise (http://enterprise.github.com) solution. As I don't own a company that could potentially be buying it, I don't feel confortable to lie, just to get a copy and try to see it by myself.
But I'm really interested to know what kind of strategies they used to protect the code they deliver, as it potentially can be used by any other rails application.
This question is not "How to protect my Ruby Code", but how they protected and entire appliance with not just Ruby code but a lot more dependent services, running on an ubuntu linux server.
I have some theories that could help:
They could be using Ruby Encoder to protect the ruby code
They could be using TrueCrypt to create a special partition to install all the code and needed application and have created a special loader to somehow execute that code without giving read/write permission to any other user on the system.
They are currently using a modified RubyEncoder.
Source: I asked
I don't know Ruby but they say:
Does the license include access to the source code?
No. Licenses cover the use of the software only. Modification and redistribution are not permitted.
It doesn't necessarily have to be protected using any technology, which can eventually be broken. You are singing a contract, if you do not follow the regulations in it, you may end up in court. I guess it's a matter of mutual trust.
Basically, I want to get an update of the standard command-line subversion client for Windows. I used to be able to get downloads of this quite easily, but it seems like registration is required these days.
I object to registration, but equally, I prefer not to use workarounds that e.g. involve registering with details that won't stay valid.
I already have TortoiseSVN - this isn't about clients in general, but specifically about the standard command-line client. I also don't need the server stuff - just the client.
It looks like I can download the source, but building from that probably involves the usual dependency-finding issues and so on. As this is likely to be a recurring issue, I'd prefer to avoid it if possible.
I'll be more than happy with a torrent link. Googling for that specifically, though, just leads to a lot of what look like pirate versions of commercial clients.
Any ideas? Or is there some good reason for collecting these registration details that might override my objections?
EDIT
Applogies to everyone I "sigh"ed at or whatever over SlikSVN suggestions. Clearly, I need to do better at avoiding making bad assumptions.
Which site are you downloading from? Just taking a look at the download links from the SVN project home (http://subversion.apache.org/packages.html), I see four options for Windows, several of which do not have registration, at least. The SlikSVN link is free and has command line utilities.
You could also install Cygwin, which is definitely free and comes with other useful utilities.
You can get a free one here:
http://www.sliksvn.com/en/download
As you said, you can certainly download and build the source code; it's free software under the Apache License 2.0. But if you want to download an executable without Collab's registration, try SlikSvn.
Binary distributions of the subversion client are available from the official subversion site.
http://subversion.apache.org/packages.html
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
Answered:
They don't allow any kind of redistribution with 2.6, supposedly, unless you have licenses for it. But they don't sell licenses for it. But they give it away free. But, who knows, i think they just want us to buy an overpriced thing we don't need to write a free utility. I guess I'll look at NVelocity or TaHoGen...
I am concerned about placing some DLLs that go with a project, which is also free (on SF.net), but hasn't had a particular license associated with it yet. This is a bit lawerly, but hopefully not so much so that it can't be answered through experience. And there is a lot of that here :)
I think the issues is really with CodeSmith 2.6, since they have their own "custom" eula. To view the "sourcelicense.txt" you need to download the zip and open it, but i've copied the relevant parts into the post (sorry they are so long!)
Edit:
What the app does it use CodeSmith 2.6
dlls, along with a collection of
custom templates, to generate class
files/etc. We don't need the
codesmith source, only the compiled
result. Of course, those dll's will
be distributed with the application in
the .exe. The question is whether or
not stuffing them in to the repo is
somehow different (or legally more
questionable) than putting them into a
.msi/.exe installer.
I'll approach codesmith about this,
but I would like a better
understanding than I have now, is all.
They are currently not in the repo,
but it would ease things for the dev
processess if they were.
End Edit
1 MIT Licensed component (doesn't seem like an issue)
Mysql.Data.dll (not sure of the license)
CodeSmith 2.6 Freeware DLLS
Compiled to DLL form
SchemaExplorer.dll / etc
CodeSmith.Engine.dll
I'd like to be able to make the project self hosting, and not have the user go traipsing around, downloading and/or compiling copies of the source (especially if they find a newer version or older verision, which could easily happen with the MIT/msql components.)
There will be nice instructions if the DLLs can't be included, but life is infinitely simpler if they can, and there are no chances of the project going "dead" if one of them is suddenly yanked.
SOURCE CODE LICENSE (from CodeSmith 2.6 eula/sourcelicense.txt)
The SOURCE CODE is protected by United States copyright laws and international copyright treaties, as well as other intellectual property laws and treaties. The SOURCE CODE is licensed, not sold.
GRANT OF LICENSE. This EULA grants you the following rights:
Source Code. You may install and compile one copy of the SOURCE CODE on a single computer. The primary user of the computer on which the SOURCE CODE is installed may make a second copy for his or her exclusive use on a portable computer.
Storage/Network Use. You may also store or install a copy of the SOURCE CODE on a storage device, such as a network server, used only to install or compile the SOURCE CODE on your other computers over an internal network; however, you must acquire and dedicate a license for each separate computer on which the SOURCE CODE is installed or compiled from the storage device. A license for the SOURCE CODE may not be shared or used concurrently on different computers.
Use and Modification. SMITH grants you the right to use and modify the SOURCE CODE to better fit your needs. You may not distribute the SOURCE CODE, or any modified version of the SOURCE CODE, in any form. Any modifications made to the SOURCE CODE will continue to be subject to the terms and conditions of this EULA. Any modified versions of the SOURCE CODE may only be executed in object form by users also owning a SOURCE CODE LICENSE or by users owning a CodeSmith Professional license.
Use of Generated Output. You may distribute the output of your custom templates or the included templates in any way.
DESCRIPTION OF OTHER RIGHTS AND LIMITATIONS.
Separation of Components. The SOURCE CODE is licensed as a single product.
Redistribution. The SOURCE CODE may not be redistributed in any way.
Custom Template Distribution. You may distribute your custom templates for the SOURCE CODE only if they are offered free of charge.
No Rental. You may not rent, lease, lend or provide commercial hosting services to third parties with the SOURCE CODE.
Non-Transferable. This license may not be transfered or sold in any way.
Termination. Without prejudice to any other rights, SMITH may terminate this EULA if you fail to comply with the terms and conditions of this EULA. In such event, you must destroy all copies of the SOURCE CODE and all of its component parts.
ADDITIONAL SOFTWARE/SERVICES.
Support Services. SMITH may, but is not obligated to, provide you with support services related to the SOURCE CODE.
Supplements. This EULA applies to additional software and updates of the SOURCE CODE, including without limitation supplements, service packages, hot fixes, or add-on components (collectively "Supplements") that SMITH may provide to you or make available to you after the date you obtain your initial copy of the SOURCE CODE, unless other terms are provided along with such Supplements.
COPYRIGHT. All title and copyrights in and to the SOURCE CODE (including but not limited to any images, photographs, animations, video, audio, music, text, SAMPLE CODE, and "applets" incorporated into the SOURCE CODE) and any copies of the SOURCE CODE are owned by SMITH. The SOURCE CODE is protected by copyright laws and international treaty provisions. Therefore, you must treat the SOURCE CODE like any other copyrighted material except that you may install the SOURCE CODE.
First: Stackoverflow is not a lawyer and can not provide legal advice. Take any legal information here with a grain of salt, and ask a lawyer if it matters.
Umm, that isn't anything close to a free software license, so I don't think it follows sf.net rules.
It doesn't grant you any permission to redistribute, either. In fact, it bars it:
2.2 Redistribution. The SOURCE CODE may not be redistributed in any way.
Possibly, your DLL is a "custom template", in which case it must be distributed free of charge, which violates clause 1 of the Open Source Definition
Custom Template Distribution. You may distribute your custom templates for the SOURCE CODE only if they are offered free of charge.
Other than that, you definitely need to clarify what you're doing.
I'm not familiar with what CodeSmith does, and I don't know exactly what you're doing with it. Obviously, you aren't going to redistribute source code, but they don't seem all that concerned with what you might redistribute.
There's that "Use of Generated Output" clause; are you going to be distributing template output only? Were you going to change their source code for this project? Without knowing the answers to questions like these, I can't advise you.
You could clarify what you're doing, or ask CodeSmith. I'm not sure that finding a lawyer who can answer your specific questions is going to be easy, as there's a lot of technical stuff going on in that license.
My organization has begun slowly repurposing itself to a less product-oriented business model and more contract-oriented business model over the last year or two. During the past year, I was shifted into the new contracting business to help put out fires and fill orders. While the year as a whole was profitable (and therefore, by at least one measure, successful, we had a couple projects that really dinged our numbers for the year back around June.
I was talking with my manager before the Christmas holiday, and he mentioned that, while he doesn't like the term "post-mortem" (I have no idea what's wrong with the term, any business folks or managers out there know?), he did want to hold a meeting sometime mid-January where the entire contract group would review the year and try to figure out what went right, what went wrong, and what initiatives we can perform to try to improve profitability.
For various reasons (I'll go into more detail if it's requested), I believe that one thing our team, and indeed the organization as a whole, would benefit from is some form of organized code-sharing. The same things get done again and again by different people and they end up getting done (and broken) in different ways. I'd like to at least establish a repository where people can grab code that performs a certain task and include (or, realistically, copy/paste) that code in their own projects.
What should I propose as a workable common source repository for a team of at least 10-12 full-time devs, plus anywhere from 5-50 (very) part time developers who are temporarily loaned to the contract group for specialized work?
The answer required some cultural information for any chance at a reasonable answer, so I'll provide it here, along with some of my thoughts on the topic:
Developers will not be forced to use this repository. The barrier to
entry must be as low as possible to
encourage participation, or it will
be ignored. Sadly, this means
that anything which requires an
additional software client to be
installed and run will likely fail.
ClickOnce deployment's about as
close as we can get, and that's awfully iffy.
We are a risk-averse, Microsoft shop. I may be able to sell open-source solutions, but they'll be looked upon with suspicion. All devs have VSS, the corporate director has declared that VSTS is not viable going forward. If it isn't too difficult a setup and the license is liberal, I could still try to ninja a VSTS server into the lab.
Some of my fellow devs care about writing quality, reliable software, some don't. I'd like to protect any shared code written by those who care from those who don't. Common configuration management practices (like checking out code while it's being worked on) are completely ignored by at least a fifth of my colleagues on the contract team.
We're better at writing processes than following them. I will pretty much have to have some form of written process to be able to sell this to my manager. I believe it will have to be lightweight, flexible, and enforced by the tools to be remotely relevant because my manager is the only person who will ever read it.
Don't assume best practices. I would very much like to include things like mandatory code reviews to enforce use of static analysis tools (FxCop, StyleCop) on common code. This raises the bar, however, because no such practices are currently performed in a consistent manner.
I will be happy to provide any additional requested information. :)
EDIT: (Responsing to questions)
Perhaps contracting isn't the correct term. We absolutely own our own code assets. A significant part of the business model on paper (though not, yet, in practice) is that we own the code/projects we write and we can re-sell them to other customers. Our projects typically take the form of adding some special functionality to one of the company's many existing software products.
From the sounds of it you have a opportunity during the "post-mortem"to present some solutions. I would create a presentation outlining your ideas and present them at this meeting. Before that I would recommend that you set up some solutions and demonstrate it during your presentation. Some things to do -
Evangelize component based programming (A good read is Programming .NET Components - Jubal Lowy). Advocate the DRY (Don't Repeat Yourself) principle of coding.
Set up a central common location in you repository for all your re-usable code libraries. This should have the reference implementation of your re-usable code library.
Make it easy for people to use your code libraries by providing project templates for common scenarios with the code libraries already baked in. This way your colleagues will have a consistent template to work from. You can leverage the VS.NET project template capabilities to this - check out the following links VSX Project System (VS.Net 2008), Code Project article on creating Project Templates
Use a build automation tool like MSBuild (which is bundled in VS2005 and up) to copy over just the components needed for a particular project. Make this part of your build setup in the IDE (VS.NET 2005 and up have nifty ways to set up pre-compile and post-compile tasks using MSBuild)
I know there is resistance for open source solutions but I would still recommend setting up and using a continuous automation system like CruiseControl.NET so that you can leverage it to compile and test your projects on a regular basis from a central repository where the re-usable code library is maintained. This way any changes to the code library can be quickly checked to make sure it does not break anything, It also helps bring out version issues with the various projects.
If you can set this up on a machine and show it during your post-mortem as part of the steps that can be taken to improve, you should get better buy since you are showing something already working that can be scaled up easily.
Hope this helps and best of luck with your evangelism :-)
I came across this set of frameworks recently called the Chuck Norris Frameworks - They are available on NuGet at http://nuget.org/packages/chucknorris . You should definitely check them out, as they have some nice templates for your ASP.NET projects. Also definitely checkout Nuget.
organize by topic, require unit tests (feature-level) for check-in/acceptance into library; add a wiki to explain what/why and for searching
One question: You say this is a consulting group. What code assets do you have? I would think most of your teams' coding efforts would be owned by your clients as part of your work-for-hire contract. If you are going to do this you need to make absolutely certain that your contracts grant you rights to your employees' work.
Maven has solved code reuse in the Java community - you should go check it out.
I have a .NET developer that's devised something similar for our internal use for .NET assemblies. Because there's no comparable .NET Internet community, this tool will just access an internal repository in our corporate network. Otherwise will work rather much the way Maven does.
Maven could really be used to manage .NET assemblies directly (we use it with our Flex .swf and .swc code modules) is just .NET folk would have to get over using a Java tool and would probably have to write a Maven plugin to drive msbuild.
First of all for code organization check out Microsoft Framework Design Guidelines at http://msdn.microsoft.com/en-us/library/ms229042.aspx and then create a central Location source control for the new framework that your going to create. Set up some default namespaces, assemblies for cleaner seperation and make sure everyone gets a daily build.
Just an additional point, since we have "shared code" in my shop as well.
We found out this is very much a packaging issue:
Whatever code your are producing or tool you are using, what you should have is a common build tool able to package your sources into a "delivery component", with everything used to actually execute the code, but also the documentation (compressed), and the source (compressed).
The main interest into having a such a "delivery package unit" is to have as less files to deploy as possible, in order to ease the download of those units.
The build process can very well be managed by Maven or any other (ant/nant) tool you want.
When some audit team want to examine all our projects, we just deploy on their post the same packages we deploy on a production machine, except they will un-compressed the source files and do their work.
Since our source files also includes whatever files are needed to compile them (like for instance eclipse files), they even can re-compile those projects in their development environment).
That way:
Developers will not be forced to use this repository. The barrier to entry must be as low as possible to encourage participation, or it will be ignored: it is just a script to execute to get the "delivery module" with everything in it they need (a maven repository can be used for that too)
We are a risk-averse, Microsoft shop: you can use any repository you want
Some of my fellow devs care about writing quality, reliable software, some don't: this has nothing to do with the quality of code written in these packages modules
We're better at writing processes than following them: the only process involved in this is the packaging process, and it can be fairly automated
Don't assume best practices: you are not forced to apply any kind of static code analysis before packaging executable and source files.