“It was the best of times, it was the worst of times, it was the age of wisdom, it was the age of foolishness, it was the epoch of belief, it was the epoch of incredulity, it was the season of Light, it was the season of Darkness, it was the spring of hope, it was the winter of despair, we had everything before us, we had nothing before us…”, penned Charles Dickens in 1859’s A Tale of Two Cities.
I was going to start off listing a series of what I think are easy questions that I reckon everyone in technology should be able to answer even if they are not or have never been involved with writing software. I gave this some serious thought and decided (perhaps a little arbitrarily) that, actually, I’m really only interested in one single question for now and that is ‘should software be tested’?
In part 1 and part 2 of the ‘[ ________ ] is the Best Policy’ series, we looked at how open source policies can quite often lead to the wrong type of behavior in an organization. As we saw, 41% of development professionals stated they are generally looking for the path of least resistance when it comes to compliance with policies — many of whom will put a non-trivial amount of effort into working such policies.
At the Black Hat 2014 Conference in Las Vegas, Mark Miller, Community Advocate for Nexus, and Executive Producer of the OWASP 24/7 Podcast Series, presented the third installment of the OWASP security news quizz, “Wait, Wait! Don’t Pwn Me!”. Play along and see how many news stories you can identify for the month of August […]
In Part 1, ‘[ ________ ] is the Best Policy, we looked at some of the common aspects of an open source policy and discussed how our recent survey discovered that 41% of people think that policies are not enforced. Now in Part 2, we will look at how effective policies are when considering security concerns.
Open source has been around for donkey’s years but until recently the persuasive argument of “many eyeballs” was the guiding policy when using open source. In comes the recent industry shock wave we all know as Heartbleed and now many of us are re-evaluating the cost of free software.
It is live! Within an extremely short turnaround time the Sonatype Operations team has coordinated certificates and other setup with our excellent CDN provider Fastly and you can now all enjoy the content of the Central Repository via HTTPS/SSL.
I remember it clearly. Sitting down for breakfast, I opened the Sydney Morning Herald to see the latest headlines in Australia for the day. As I shuffled through the paper, I finally landed upon the Technology section and then noticed pages and pages of “help wanted” adds.
We’ve had quite a bit of public scrutiny recently over how we’ve chosen to provide SSL access to Central for the last two years. At Sonatype, we have a history of investments in the Maven Central community, all of which are focused on improving the quality of the contents, increasing reliability and performance of delivery, and yes, even strengthening security which is often not popular (how many gripes can you find about why we require PGP signatures on artifacts?)
While Repository Health Checks are valuable, we just released something even better: the CLM 1.11 Dashboard. First of all, it helps you answer the first two critical open source vulnerability questions: did we ever use that and where is it? And, you can find out the answers to those questions in about three seconds.