Techrights logo

IRC: #boycottnovell @ FreeNode: December 31st, 2012

Join us now at the IRC channel.

*abeNd-org has quit (Ping timeout: 252 seconds)Dec 31 01:59
*pidgin_log has quit (Quit: Leaving.)Dec 31 10:31
*pidgin_log ( has joined #boycottnovellDec 31 10:31
*MinceR_ ( has joined #boycottnovellDec 31 13:26
*MinceR_ has quit (Changing host)Dec 31 13:26
*MinceR_ (~mincer@unaffiliated/mincer) has joined #boycottnovellDec 31 13:26
*MinceR has quit (Ping timeout: 265 seconds)Dec 31 13:26
*MinceR_ is now known as MinceRDec 31 13:32
*ChanServ gives channel operator status to MinceRDec 31 13:33
*schestowitz has quit (Remote host closed the connection)Dec 31 13:59
*schestowitz (~schestowi@unaffiliated/schestowitz) has joined #boycottnovellDec 31 14:00
*ChanServ gives channel operator status to schestowitzDec 31 14:00
*abeNd-org (~Keith@ has joined #boycottnovellDec 31 14:15
*puppywatch has quit (Remote host closed the connection)Dec 31 16:41
*libertybox_ has quit (Remote host closed the connection)Dec 31 16:41
*libertybox_ ( has joined #boycottnovellDec 31 16:44
*puppywatch ( has joined #boycottnovellDec 31 16:44
schestowitzneed to validate something for gov projectDec 31 17:07
schestowitzOn build standards... Build standards establish a secure process by which software is assured to be safe to deploy and also remains safe when it is updated. The process is composed of a set of pertinent guidelines.Dec 31 17:07
schestowitzIn practical terms this means we should modify all code in one consistent environment, namely our git repositoryDec 31 17:55
schestowitzA management system is needed for centralised flaw monitoring. For this we may require a bug tracking package like Trac or Bugzilla.Dec 31 17:55
schestowitz 31 17:56
TechrightsBotTitle: Home :: Bugzilla :: .::. Size~: 9.29 KBDec 31 17:56
TechrightsBotTitle: The Trac Project .::. Size~: 15.59 KBDec 31 17:56
schestowitzit has just occurred to me that we also need a database-driven system that keeps track of what software we install (and for whom) and what the latest flaws/software updates are, where the goal is to keep clients with the latest or at least the latest secure version of software like CMS, Samba, etc.Dec 31 17:58
schestowitzwe required something like this at the time.Dec 31 17:59
schestowitzControl files, or files specifying input parameters and compilation settings, should be maintained in a version control system as specified in Requirement 1. These files, in turn, help consistently build binary files from the source code. This ensures that no manual intervention or judgement can lead us to producing different binaries from the same source code.Dec 31 18:28
schestowitzThe change management package, git in this case, should keep track of the modifier/s of the aforementioned files (*Requirement *).Dec 31 19:44
schestowitzRules should be specified -- and developers be familiarised with them -- for handling of newly-discovered flaws. This can be done using a mailing list, perhaps with automated mails sent to it when a flaw is found and then acted upon.Dec 31 19:48
schestowitzItems that are peripheral to source code, assuming this code is developed by a third party for distribution (e.g. publicly-available FOSS project), should be secured from tampering by untrusted people from inside and outside our company. Git is authentication-based and requires server access with personal credentials.Dec 31 20:06
schestowitz"The way that products are assembled must be consistent and repeatable i.e., the build process should be automated."Dec 31 20:14
schestowitzThis can be assured with a MakeFile, which itself is added to the git repository and edited therein.Dec 31 20:14
*abeNd-org has quit (Quit: Leaving.)Dec 31 20:47
schestowitzThis one deals with a procedural need to learn from mistakes and follow through a careful analysis of root causes. If documentation is created before and throughout development, e.g. in the wiki with diagrams, tables, or text, then together with revision control it should be possible to do.Dec 31 21:13
schestowitz"The Developer's products must behave as designed. i.e. they should have reason to believe that they are correct. Using non-trivial test cases, Developers should be able to demonstrate evidence of security and functional testing. This testing should cover the whole scope of the product.Dec 31 21:16
schestowitzA framework for thorough testing is needed. This can be facilitated by testing software (QA applications) and staff with background/qualifications in the area.Dec 31 21:16
schestowitzFor Free/Open Source software, SELinux might be worth utilising. In addition, languages can be set to be more or less permissive, depending on various settings including the level of verbosity. Suffice to say, choosing a stable branch of the platform, language/s and tool chain is advisable. Debian (Stable) is very stable and mature as it uses reliable rather than cutting-edge packages.Dec 31 21:21
schestowitzAs explained earlier (*Requirement 2*), bugs can be marked in a central database. Also see fulfilment of *Requirement 5*.Dec 31 21:24
schestowitz"The Developer should use a coding standard that is applied to all code in their finished products (including third-party components). The coding standard and associated processes must ensure that common software defects and easily avoided security weaknesses are not introduced into the product's code."Dec 31 21:27
schestowitzThis is a matter of coding consistency and style, including the avoidance of errors repeating in both locally-developed code and third-party code. If code is developed in-house, it can be made to assimilate to the  third-party components to the degree possible, including re-use where applicable.Dec 31 21:27
schestowitz*Build Systems* -  we must use a single cohesive build system that compiles a consistency-preserving package even when the system itself matures. If it is not backward-compatible, then there may be issues.Dec 31 21:32
schestowitz*Development issue tracking/support* - Requirement 2 says: "Updates that fix security flaws must be actively advertised to supported customers and categorised according to the severity of the flaw." Selection of applications here is not yet determined.Dec 31 21:35
schestowitz---++ Chosen SoftwareDec 31 21:51
schestowitzNarrowing it down to software which is Free/Open Source, we have the following:Dec 31 21:51
schestowitz---+++ Issue TrackingDec 31 21:51
schestowitzWikipedia has [[][this detailed comparison of issue-tracking systems]]. The Free/Open Source options are Bugzilla, Debbugs, Fossil, GNATS, GLPI, Launchpad, Liberum Help Desk, LibreSource, MantisBT, OTRS, Redmine, Request Tracker, Roundup, and Zentrack.Dec 31 21:51
TechrightsBotTitle: Bad title - Wikipedia, the free encyclopedia .::. Size~: 17.35 KBDec 31 21:51
schestowitz---+++ Change TrackingDec 31 21:51
schestowitzWe can rely on Git for all our needs.Dec 31 21:51
schestowitz---+++ Compiler/ParserDec 31 21:51
schestowitzGNU tools or interpreted language such as PHP may do. It depends on the project ans its dependants.Dec 31 21:51
schestowitz---+++ Operating System/EnvironmentDec 31 21:51
schestowitzWe standarside and stick with Debian inside the company.Dec 31 21:51
schestowitzSome projects, JIRA for example, would not fit well with their licence.Dec 31 22:29

Generated by 2.6 by Marius Gedminas - find it at!