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 (~roy@host86-167-158-193.range86-167.btcentralplus.com) has joined #boycottnovell | Dec 31 10:31 | |
| *MinceR_ (~mincer@94-21-206-86.pool.digikabel.hu) has joined #boycottnovell | Dec 31 13:26 | |
| *MinceR_ has quit (Changing host) | Dec 31 13:26 | |
| *MinceR_ (~mincer@unaffiliated/mincer) has joined #boycottnovell | Dec 31 13:26 | |
| *MinceR has quit (Ping timeout: 265 seconds) | Dec 31 13:26 | |
| *MinceR_ is now known as MinceR | Dec 31 13:32 | |
| *ChanServ gives channel operator status to MinceR | Dec 31 13:33 | |
| *schestowitz has quit (Remote host closed the connection) | Dec 31 13:59 | |
| *schestowitz (~schestowi@unaffiliated/schestowitz) has joined #boycottnovell | Dec 31 14:00 | |
| *ChanServ gives channel operator status to schestowitz | Dec 31 14:00 | |
| *abeNd-org (~Keith@76.0.118.52) has joined #boycottnovell | Dec 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_ (~liberty@host86-167-158-193.range86-167.btcentralplus.com) has joined #boycottnovell | Dec 31 16:44 | |
| *puppywatch (~PuppyWatc@host86-167-158-193.range86-167.btcentralplus.com) has joined #boycottnovell | Dec 31 16:44 | |
| schestowitz | need to validate something for gov project | Dec 31 17:07 |
|---|---|---|
| schestowitz | On 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 |
| schestowitz | In practical terms this means we should modify all code in one consistent environment, namely our git repository | Dec 31 17:55 |
| schestowitz | A 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 | http://www.bugzilla.org/ http://trac.edgewall.org/ | Dec 31 17:56 |
| TechrightsBot | Title: Home :: Bugzilla :: bugzilla.org .::. Size~: 9.29 KB | Dec 31 17:56 |
| TechrightsBot | Title: The Trac Project .::. Size~: 15.59 KB | Dec 31 17:56 |
| schestowitz | it 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 |
| schestowitz | we required something like this at the time. | Dec 31 17:59 |
| schestowitz | Control 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 |
| schestowitz | The change management package, git in this case, should keep track of the modifier/s of the aforementioned files (*Requirement *). | Dec 31 19:44 |
| schestowitz | Rules 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 |
| schestowitz | Items 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 |
| schestowitz | This 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 | |
| schestowitz | This 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 |
| schestowitz | A 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 |
| schestowitz | For 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 |
| schestowitz | As 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 |
| schestowitz | This 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 Software | Dec 31 21:51 |
| schestowitz | Narrowing it down to software which is Free/Open Source, we have the following: | Dec 31 21:51 |
| schestowitz | ---+++ Issue Tracking | Dec 31 21:51 |
| schestowitz | Wikipedia has [[https://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems][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 |
| TechrightsBot | Title: Bad title - Wikipedia, the free encyclopedia .::. Size~: 17.35 KB | Dec 31 21:51 |
| schestowitz | ---+++ Change Tracking | Dec 31 21:51 |
| schestowitz | We can rely on Git for all our needs. | Dec 31 21:51 |
| schestowitz | ---+++ Compiler/Parser | Dec 31 21:51 |
| schestowitz | GNU tools or interpreted language such as PHP may do. It depends on the project ans its dependants. | Dec 31 21:51 |
| schestowitz | ---+++ Operating System/Environment | Dec 31 21:51 |
| schestowitz | We standarside and stick with Debian inside the company. | Dec 31 21:51 |
| schestowitz | Some projects, JIRA for example, would not fit well with their licence. | Dec 31 22:29 |
Generated by irclog2html.py 2.6 by Marius Gedminas - find it at mg.pov.lt!