Revision 1.2 - 07/10/03 Revision 1.1 - 05/28/03 Answer in whatever length necessary for completeness. +----------------------------------------+ | First Name | Peter Sandor_________ | |----------------+-----------------------| | Last Name | Mazinger_____________ | |----------------+-----------------------| | E-mail address | ps.m@gmx.net_________ | |----------------+-----------------------| | Date | 2004.10.14___________ | +----------------------------------------+ Please take a few minutes to fill out the following questionnaire so that our team may be able to better understand about your possible future relationship with our herd. This basic questionnaire should not take long to complete. Space is also provided for open-ended responses, should you wish to tell us more. We encourage you to share with us anything you think might be useful or important for us to know, in terms of supporting yours and our security efforts. ------------------------------------------------------------------------ These 10 questions are directly related to portage and the gentoo way of doing things its important that you the developer have a good understanding of these things. 1. You change a package's ebuild to install an init script. Previously, ********the package had no init script at all. ********Is a revision bump necessary? no, the users who already built it are using it already, only the new ones will benefit of it 2. A user submits a "live" CVS ebuild. What would be a preferable ********alternative to such an ebuild? snapshot cvs, live cvs could break after a cvs update 3. A user submits a brand-new ebuild for a new package. What are the ********proper steps (including cvs commands) to take to add ********this ebuild to the tree? audit/test the ebuild, talk to peers, or ask on #gentoo-dev if the ebuild would be good addition mkdir new-app cvs add new-app cd new-app cp /new-app/new-app.ebuild . echangelog "initial commit of new-app. Thanks to user X.Y for this ebuild on bug #" cp ../../skel.metadata.xml , ;# adapt # create digest ebuild new-app.ebuild digest cd files # not necessary if FEATURES="cvs digest autoaddcvs" cvs add digest-new-app cd .. # instead of the above from create digest # repoman fix can be used cvs add Changelog cvs add metadata.xml cvs add new-app.ebuild repoman --pretend scan repoman ci -m "initial commit of new-app. Thanks to user X.Y for this ebuild on bug #" 4. A user submits an ebuild that has numerous technical problems and ********violates policy. How would you handle that situation? ask him to correct it 5. You have a set of new ebuilds that could potentially benefit ********from a global USE flag. What steps should be taken before ********such a USE flag is implemented? discuss it w/ devs, probably on gentoo-dev 6. You're creating an ebuild. Unfortunately, the ebuild's 'make install' ********target causes numerous access violations. What is the best ********course of action to take to have a clean, straightforward ********ebuild? "inspire" myself from others (debian,mandrake,redhat,openpkg) 1. if the Makefile supports make install DESTDIR= use it 2. else if the Makefile works correctly w/ einstall, use it 3. else if the Makefile does not work correctly patch the Makefile so that it behaves for 1. or 2. 4. else if Makefile not usable use dobin/doexe/dosbin/dodoc to install 7. You're creating an ebuild that needs a patch. The patch is ********nontrivially large - bigger than 20kbytes. Where should ********the patch be kept? tarball uploaded to gentoo distfiles mirrors 8. You're creating an ebuild that has its own license - one that ********doesn't exist in /usr/portage/licenses/. What is the proper ********course of action? make sure the license allows to have an ebuild, add first license, after that the ebuild 9. (a) You wish to mark an ebuild "stable," taking it out of ~ARCH ********KEYWORDS. It's a critical system library. What steps should ********be taken to do so? provide a smooth upgrade path w/o breaking compatibility contact maintainer, discuss it on gentoo-core/dev, ask different arch maintainers to do so for their arch ** (b) You wish to mark an ebuild "testing," putting it into ~ARCH ********KEYWORDS. It was previously hard-masked in package.mask. ********What should be done prior to doing so? contact the dev who hard-masked it ** (c) You wish to mark an ebuild "stable." It is a popular ********application, but no other ebuilds depend on it. ********What should be done first? it has to be in ~arch 30 days w/o bugs contact maintainer, do it only for tested arch, ask arch maintainers to do so for their arch 10. You're committing a user-submitted ebuild. What should be in the ********initial ChangeLog? credit to the user who submitted it, move non-gentoo headers from the provided ebuild to ChangeLog, replacing w/ correct gentoo headers ------------------------------------------------------------------------ * Do you routinely monitor or participate in any security oriented newsgroups, mailing lists, etc.? If so, please tell us which. grsecurity,grsecurity-forum,cert,openpkg-security-announcements,redhat-errata * What do you see as the most significant security related issues for the next year or two? crypto_______________ * Do you work well independently? yes__________________ * Do you work well with others? probably_____________ * Are you currently now or in the past been a participating member of another open source projects if so which? no * Initially what would you like to do with gentoo? hardened/uclibc * Please use this field to share with us anything you wish on the subject of IT security. * What other information would be useful for you to tell us about your security practices, ideas, needs, and capabilities? no programming knowledge, linux experience since 1994 * Please tell us a little bit about the following that you have may have experience or a passion with. [ ] - auditing [x] - cryptography [x] - firewalls [ ] - forensics [ ] - hacking [ ] - honeypots [x] - host security [x] - incident handling [x] - intrusion detection [x] - intrusion prevention [ ] - law [ ] - miscellaneous [x] - network security [ ] - news [ ] - operating systems [x] - penetration testing [ ] - privacy [ ] - projects [ ] - secure programming [ ] - security basics [ ] - security events [ ] - security papers [ ] - security tools [ ] - trusted operating systems [ ] - viruses [x] - vpn [ ] - vulnerability development [ ] - vulnerability assessments [ ] - web application security ------------------------------------------------------------------------ Thank you for completing this questionnaire. The information you have provided will help us to design resources and activities that try match your abilities. [Team GentooHardened] ------------------------------------------------------------------------