Bug#733912: RFP: s6 - a small suite of programs for UNIX, designed to allow process supervision
Package: s6 Version: 1.1.1 Severity: wishlist Please pack s6[0], a small suite of programs for UNIX, designed to allow process supervision (a.k.a service supervision), in the line of daemontools and runit. [0] http://skarnet.org/software/s6/ Cheers, Serge -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733913: RFP: perp, aka the perpetrator: a persistent process supervisor and service managment framework for un!x
Package: perp Version: 2.07 Severity: wishlist Please pack perp[0], aka the perpetrator: a persistent process supervisor and service managment framework for un!x. [0] http://b0llix.net/perp/ Cheers, Serge -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733914: RFP: libcurvecpr, a low-level, networking-independent implementation of Daniel J. Bernstein's CurveCP
Package: libcurvecpr Version: 0.1.1 Severity: wishlist Please pack libcurvecpr[0], a low-level, networking-independent implementation of Daniel J. Bernstein's CurveCP. [0] https://github.com/impl/libcurvecpr/ Cheers, Serge -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733915: RFP: s6 -- a small suite of programs for UNIX, designed to allow process supervision
Package: wnpp Severity: wishlist * Package name: s6 Version : 1.1.1 Upstream Author : ska s...@skarnet.org * URL : http://skarnet.org/software/s6/ * License : ISC Programming Lang: C Description : s6 - a small suite of programs for UNIX, designed to allow process supervision s6 is a small suite of programs for UNIX, designed to allow process supervision (a.k.a service supervision), in the line of daemontools and runit. Why another supervision suite ? Supervision suites are becoming quite common. Today, we already have: Good (?) old System V init, which can be made to supervise services if you perform /etc/inittab voodoo. BSD init can also be used the same way with the /etc/ttys file, but for some reason, nobody among BSD developers is using /etc/ttys to this purpose, so I won't consider BSD init here. daemontools, the pioneer daemontools-encore, Bruce Guenter's upgrade to daemontools runit, Gerrit Pape's suite, well-integrated with Debian perp, Wayne Marshall's take on supervision and even Upstart, Ubuntu's init system, which performs real supervision. Fedora's systemd and MacOSX's launchd are very similar in spirit to Upstart, so the same comments apply to them. Why is s6 needed ? What does it do differently ? Here are the criteria I used. Supervision suites should not wake up unless notified. System V init fails the test: it wakes up every 5 seconds, for the reason that /dev/initctl might have changed. m( daemontools fails the test: it wakes up every 5 seconds to check for new services. daemontools-encore does the same. the current version of runit fails the test: it wakes up every 14 seconds. But this is a workaround for a bug in some Linux kernels; there is no design flaw in runit that prevents it from passing the test. perp works. Upstart works. s6 works. By default, s6-svscan wakes up every 5 seconds, to emulate svscan behaviour; but it can be told not to do so. (s6-svscan -t0) Supervision suites should provide a program that can run as process 1. System V init and Upstart are process 1, so no problem here. daemontools was not designed to take over init, although it can be made to work with enough hacking skills. Same thing with daemontools-encore. runit provides an init functionality, but the mechanism is separate from the supervision itself; the runit process, not the runsvdir process, runs as process 1. This lengthens the supervision chain. perp was not designed to run as process 1. It probably could be made to work too without too much trouble. s6-svscan was designed from the start to be run as process 1, although it does not have to. Supervision suites should be bug-free, lightweight and easy to understand. daemontools, daemontools-encore, runit and perp all qualify. All of this is excellent quality code, unsurprisingly. This is where System V init and Upstart fail, hard. SysVinit is too big for what it (poorly) does. Upstart is clever, but it's waay too complex. Come on people... using ptrace to watch your children fork()? Linking process 1 against libdbus? This is insanity. Process 1 should be absolutely stable, it should be guaranteed to never crash, so the whole of its source code should be under control. At Upstart's level of complexity, those goals are outright impossible to achieve, so the Upstart approach is flawed by design. Of course, systemd and launchd suffer from the same problem. Guys, I'm glad you eventually realized that supervision was a good thing, and that it had to be rooted in process 1, but that does not mean that all the supervision logic has to go into process 1. No, really. s6, which has been designed with embedded environments in mind, tries harder than anyone to pass this. It tries so hard that s6-svscan and s6-supervise, the two long-running programs that make the supervision chain, do not even allocate heap memory, and their main program source files are less than 500 lines long. Supervision suites should provide a basis for high-level service management. Neither System V init, daemontools, runit or perp provides any hooks to wait for a service to go up or down. runit provides a waiting mechanism, but it's based on polling, and the ./check script has to be manually written for every service. daemontools-encore qualifies: the notify script can be used for inter-service communication. But it's just a hook: all the real notification work has to be done by the notify script itself, no notification framework is provided. Upstart already is a service management tool. But, again, it fails the test of simplicity: it does in process 1 what can and should be done outside of process 1. Process supervision is not the same as service management, and Upstart confuses the two. So do systemd and launchd. s6 comes with libftrig, an event notification library, and command-line tools based on this library, thus
Bug#733717: [Please add Serge Pawlowicz as a Debian Maintainer]
Package: debian-maintainers Severity: normal Hi, I will be using the subkey deb...@pawlowicz.name for debian-related stuff. cheers, Serge -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.10.23-vs2.3.6.8-beng (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Comment: Add Serge Pawlowicz deb...@pawlowicz.name as a Debian Maintainer Date: Tue, 31 Dec 2013 07:01:55 + Action: import Recommended-By: Bartosz Fenski fe...@debian.org Agreement: http://lists.debian.org/debian-newmaint/2013/12/msg00037.html Advocates: http://lists.debian.org/debian-newmaint/2013/12/msg00038.html Data: -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.15 (GNU/Linux) mQINBE79MR0BEADUtX3y04xcCTKQv/eO8e1P6XwJMhr54bD1E5NiDAgibr3x19g9 FcaQjxdVIRVK5gEcqgjhwpSNStHNVoCLqag0AAwXnP6Z5emXEfgazKDRyg0Pu3Vn yJRvU/GbVQXnNFenAl4DnIkdzWfJjBn4/fG/XqHTp3Xp6dy+JCR9FN0QolSzQGV3 tbj/nBli0hUVV2H5tS4fW6iylRW6VWLY3MT4JCKrAirOcTuLFnbXMe1A6b4Y3Qwr UoRaQZxOZEXbJqJuiK7YYB6roBI9D+6/PDQLU0mYW6SXNW0cYhmO02EB2tvm dlZr4g//LyGrsIN6IkBPne++zHS9aAacZcsJv5PxmAM1Z8x3Gw3u+UnxD3q8ybOJ JUOZezZwuNcbjLN86Lqi97mVduvrT++twwuLE37RKsObZ0IMNsw7rLspVLukKSWZ ySpIikZx/4MZZ1W3ANd1GbVkPLk51cqM0Ss3+/0VFCRhNN8xZEwh6dlNgHwAcZVJ 03tA+VGRFlpcMos9GjXuOcJPLgHGvA0id2sDBC+/aPcAnRPszFaGqV02PmQneWY1 BHPrcuys6es5cqbCOsz1+XgCJLMmgIhRrFuHVxuHgw1amz1G5Lb3mj2B8Ney26fB cwIk5xeMI+2osdKAOa7/VN8gRYvrp/qo663OOW6kPzMRsOP0ddknj8reVwARAQAB tClTZXJnaXVzeiBQYXfFgm93aWN6IChbZ251XSkgPHNlckBnbnUub3JnPokCOAQT AQIAIgIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AFAk79QYwACgkQ0N8ZQ2Eo NDF//A/+KSLOWrQ1VDZPd2Fn0OgO7HqZV8PAHtz2WiE8RoJV02gls/LXjZV1rzNW T3YrVc5s7gdgbP30Jm/VYPf7W2Ojt5ZANy7SFfHRipG5+P7aU9p0SszZMxBzyorv woevfzlhIAjXzqbphF3eCu+TTbsWGcKzPSl1YQzgPwyNhsyVhpU4k8/W/xTxnY3d AFWqZSMkJwk4P2puy+nqwEgMNyW/x/GAfsdgPPOivuVM3/tpX/xtmVbPL+mc9lF5 xCL5sfNB+LRAaB/zR1WnbUCugNDoTjCXhL1sck3ktKSyyPU7uSLKzeMj1O2uKWiJ gDhIQfLHwO9aaJoiAfGEExerlDpSLwkxkMiQ9ZSFmLFI31BeGKJ2p9EVcLqOtS6g FsnQ5pc+fiQYJ7amReyao8UycR1NJAVxT7k3VcbilZwudu32LGvMI7Z9+TJP5MHy uCo5gkfVsvIEiwYtuumtXEFNKQ09nmmHA2wNfv7MW4hk02mJG5K/0ARf1WFmqwBS sF4zs+4jw4vwlaTxrHL7U4LpxTg5IKwPeicpsHjd9XRc/Azsi3qX1Stf+/rAt7gn xf1YyIztWfIOwMDcb7ayqBSH5ljH8IeC6bBCWO8ObY2/ejzG7npJzfGAlQm8swBY AwtdppeQl+SthFS/GAowbOziibh5jusTLUe7rg6I2s9+WXQtf2iIRgQQEQIABgUC Tv5pTgAKCRB6gd/FIk+L6JC5AJ49K2mo11/qi8S1X5ENHhbyPoBw0QCfSEoYXloz c3DzHrsFi8wIilXONz60R1NlcmdpdXN6IFBhd8WCb3dpY3ogKGh0dHBzOi8vcGF3 bG93aWN6Lm5hbWUvKSA8c2VyZ2l1c3pAcGF3bG93aWN6Lm5hbWU+iQI4BBMBAgAi AhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCTv1BnAAKCRDQ3xlDYSg0Mcph EACd1szkHkCsZTBxQvl8tIQgn+zJ1taAH6j423rfn7oEIfry9vCQ5h0Uxr1rTAvU 7zM3y054qxbki3IZqPZ8XcQMo63s44yZxZLYdeZhUVy9Ee6VV7sEETbHqXnG+YX4 YExilAduBFLq1ZBYf9nqehRHVWmGAKR4m3MkxX7+VtanPptmH4xllYgKgQ+ihrDU 4iiWCYzSJdxHW1zDuPaiPwRzxzKPa1ab2HQuBPpYdj8fD19o5ffPGD7rdPs0wqWo uwoqL/T/2bTsdMv7TSqSbTTgrQQtN7olN0asVNkvEWsu/HsUjVVxMsCurNj0pCkI 6y8YkqmUxPSubGgmKWcIFb1URyrz9FM7wZDzHnL4N20ueSRZwM8gdbHax3VcJkYq /V2QVqt8/zPmgErCHhX9D7Uz0t0Z/Pkh5Xc0aJVagrMC/88L6y6vw4wxaoD4+jdC EOcCCwbqJEzZU5xwvXpmgQlRjAhsLs4JQZU+rk8c7e/WvC5hKtRwdvzwzEcnNFg1 RYdvTPJmM6MJwDxvb9iMJe62BXMC73m4XvZBy6OLLJg0SWVywbjBZ+CEq6+Oqx71 lUxfSME6JM9Suo9kfbF/atSB+aZvdXJ7mkTTL3bhq2Tt/V8Ym3tPkDsa6vaCLfZl AMUqkF8Ke8GULt2Ey9AiWWDCZ9k3keznusL/NXo4318mk4hGBBARAgAGBQJO/mlC AAoJEHqB38UiT4vo8nkAoMlxmHUtTd7uToTrcHXCfaHrLY9KAJwI3K5N9288n72/ o8kcaGqgWgFujdHbMNsuARAAAQEAAAD/2P/gABBKRklGAAEBAQBI AEgAAP/+AC9TZXJnaXVzeiBQYXfFgm93aWN6IDIwMDgsIEFMTCBSSUdIVFMgUkVT RVJWRUT/4gxYSUNDX1BST0ZJTEUAAQEAAAxITGlubwIQAABtbnRyUkdCIFhZWiAH zgACAAkABgAxAABhY3NwTVNGVABJRUMgc1JHQgAAAQAA9tYA AQDTLUhQICAA ABFjcHJ0AAABUDNkZXNjAAABhGx3dHB0AAAB8BRi a3B0AAACBBRyWFlaAAACGBRnWFlaAAACLBRiWFlaAAACQBRk bW5kAAACVHBkbWRkAAACxIh2dWVkAAADTIZ2aWV3AAAD1CRs dW1pAAAD+BRtZWFzAAAEDCR0ZWNoAAAEMAxyVFJDAAAEPAAACAxn VFJDAAAEPAAACAxiVFJDAAAEPAAACAx0ZXh0AENvcHlyaWdodCAoYykgMTk5 OCBIZXdsZXR0LVBhY2thcmQgQ29tcGFueQAAZGVzYwASc1JHQiBJRUM2 MTk2Ni0yLjEAABJzUkdCIElFQzYxOTY2LTIuMQAA WFlaIAAA APNRAAEBFsxYWVogAFhZWiBvogAAOPUA AAOQWFlaIGKZAAC3hQAAGNpYWVogJK+EAAC2z2Rlc2MA FklFQyBodHRwOi8vd3d3LmllYy5jaAAAFklFQyBodHRw Oi8vd3d3LmllYy5jaAAA AABkZXNjAC5JRUMgNjE5NjYtMi4xIERlZmF1bHQgUkdC IGNvbG91ciBzcGFjZSAtIHNSR0IAAC5JRUMgNjE5NjYtMi4xIERl ZmF1bHQgUkdCIGNvbG91ciBzcGFjZSAtIHNSR0IA ZGVzYwAsUmVmZXJlbmNlIFZpZXdpbmcgQ29uZGl0aW9uIGluIElF QzYxOTY2LTIuMQAALFJlZmVyZW5jZSBWaWV3aW5nIENvbmRpdGlv
Bug#310495: any chances to fix the par?
Hi, thanks a lot, Jérôme! From my preliminary tests: IT WORKS! To the package maintainer: it is strongly recommended to apply the Jérôme's patch as soon as possible and close the bug. Thanks, Serge -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#310495: bug still persists
unfortunately par still does not work properly with utf-8 documents :( -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#310495: above patch nearly works, but adds another bug
When the patch http://www.sysmic.org/dl/par/par-1.52-i18n.3.patch is applied, unfortunately there is one super-annoying bug: 1) When the text to reformat begins with a blank line the output is only blank lines. 2) When the option e is passed to eliminate superfluous lines the output is correct but, obviously, without blank lines between paragraphs. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694248: Fwd: Bug#694248: libnacl-dev: /usr/lib/libnacl.a does not include randombytes
I am really sorry, I forgot to forward the upstream's answer to the bugs system. It seems it is not related to NaCl. Do you have any ideas how we can replace randombytes() implementation? Serge -- Forwarded message -- From: D. J. Bernstein Date: Mon, Dec 3, 2012 at 10:37 AM Subject: Re: Fwd: Bug#694248: libnacl-dev: /usr/lib/libnacl.a does not include randombytes To: Sergiusz Pawlowicz sergi...@pawlowicz.name Something providing that API is of course required for NaCl's key-generation functions, but conceptually librandombytes is a separate library from libnacl---there are many reasons that an OS would want to provide a different randombytes() implementation. ---Dan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#715767: Fwd: Fwd: Bug report on nacl-tools: curvecpserver crashes with exit status 139
According to upstream, this bug will be fixed in next software version. #wontfix Serge, package maintainer -- Forwarded message -- From: D. J. Bernstein d...@cr.yp.to Date: Sun, Jun 30, 2013 at 3:26 PM Subject: Re: Fwd: Bug report on nacl-tools: curvecpserver crashes with exit status 139 To: Sergiusz Pawlowicz deb...@pawlowicz.name There are several reasons this isn't an issue; most importantly, the CurveCP portion of NaCl is in alpha test, as stated prominently in the release announcement and on curvecp.org (isn't ready for users yet). All of this code is being completely rewritten anyway. ---Dan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699397: nacl: FTBFS: dh_install: nacl-tools missing files (bin/*), aborting
Hi, I've forwarded it to upstream, waiting for a reply. S. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694248: libnacl-dev: /usr/lib/libnacl.a does not include randombytes
Thanks, Tony. I am consulting the upstream, it may take a while. Serge -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678123: armel, armhf, mips, s390 and s390x unsupported by Debian's libnacl-dev
Thanks, let me know what is your decision, but IMHO it would be useful to leave cat $(CURDIR)/build/$(SHORTHOSTNAME)/log in place, though, as it is the only available method to read builders output. cheers, Serge -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678123: armel, armhf, mips, s390 and s390x unsupported by Debian's libnacl-dev
Sorry, I have not read your patch properly, now I can understand why have you removed cat $(CURDIR)/build/$(SHORTHOSTNAME)/log and I am withdrawing my objections. I am waiting for your decision if you want to upload your patch. Thanks a lot, Serge -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678123: armel, armhf, mips, s390 and s390x unsupported by Debian's libnacl-dev
Hi, I am not able to fix the problem by myself, I have contacted the upstream and I have not received any deployable help. Unfortunately, I have no such machines on my horizon, so patches are more then welcome. Serge -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549691: wheezy - we still have that problem, and it is a huge problem, as backup scripts based on snapshots are useless
Package: lvm2 Version: 2.02.88-2 This is not the newest version. I have installed the newest one, and the situation is even worse, lvm freezes, as described in bug #659762. Kernel: Linux 3.2.18-vs2.3.2.9-beng (SMP w/8 CPU cores) This is no Debian kernel. I can agree, but it is based on debian kernel, only linux-vserver features are added. I would tend to relate the lvm problems with udev, as on squeeze a similar kernel works perfectly. S. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661622: [confirmation]
I can confirm the bug and I am working on the solution. It builds on the system, does not build on builders. Serge -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#655467: ITP: perp -- A persistent process supervisor
Package: wnpp Severity: wishlist Owner: Sergiusz Pawlowicz deb...@pawlowicz.name * Package name: perp Version : 2.05 Upstream Author : Wayne Marshall w...@b0llix.net * URL : http://b0llix.net/perp/ * License : BSD-2-clause-like Programming Lang: C89/posix Description : A persistent process supervisor about - The perp package provides a set of daemons and utilities to reliably start, monitor, log, and control a collection of persistent processes. A persistent process is any program intended to be long-running, highly available, and purpose critical. Also known and often described as a service, a persistent process normally provides some essential, on-demand system service. Programs that serve email, domain name queries, and http requests are all examples of services that are normally run as persistent processes. These are the programs that you want to start at system boot, and to continue running for as long as the system itself. These are the programs you need running in uninterrupted service, day and night, forever and ever. perp helps make sure that they do. benefits perp provides the following benefits: * easy, portable, platform-neutral service installation * fast, asynchronous service startup * consistent, reliable service execution environment * easy administration * reliable and complete logging facilities perp is similar in purpose to the venerable daemontools program last released in 2001, but provides a modern update with many advantages: * easy configuration: in place service activation and no symlinks! * single process: context switching for multiple supervisors is eliminated * everthing administered in one place, /etc/perp * service reset capability * fully FHS compatible * colorized(!) service lister, readable timestamps... * no slashpackage, no slashcommand, no slashdoc... Meanwhile, perp continues to share many of the positive attributes of daemontools: * small, portable, autoconf-less, standard C89/posix sources * daemons never malloc() * make(1) agnostic * links with dietlibc for small executables And the author is even friendly! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#655348: ITP: quicktun -- QuickTun is a simple VPN tunnel relying on NaCl library
Package: wnpp Severity: wishlist Owner: Sergiusz Pawlowicz deb...@pawlowicz.name * Package name: quicktun Version : 2.1.7 Upstream Author : Ivo Smits i...@ucis.nl * URL : http://wiki.ucis.nl/QuickTun * License : Public domain (preserve copyright notice) Programming Lang: C Description : QuickTun is a simple VPN tunnel relying on NaCl library QuickTun is probably the simplest VPN tunnel software ever, yet it's very secure. It relies on the NaCl encryption library by D. J. Bernstein. QuickTun uses the curve25519xsalsa20poly1305 crypto-box functionality of the NaCl library for secure public-key encryption. And that's about all QuickTun does; encrypting and sending data. No fancy features which would only lead to bloating the binary. In fact, QuickTun itself has only a few hundred lines of pure C code, making it dead simple to maintain, analyze, debug and fix. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#655187: [proposed package is ready]
I am looking for a sponsor for my package nacl. It builds those binary packages: libnacl-dev - High-speed software library for network communication nacl-tools - NaCl and CurveCP tools I have prepared extensive man pages by myself and packaged NaCl from scratch. To access further information about this package, please visit the following URL: http://mentors.debian.net/package/nacl Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/n/nacl/nacl_20110221-1.dsc I would be glad if someone uploaded this package for me. Kind regards, Sergiusz Pawlowicz, January 2012 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#655220: ITP: curvedns -- Forwarding implementation of the DNSCurve protocol
Package: wnpp Severity: wishlist Owner: Sergiusz Pawlowicz deb...@pawlowicz.name * Package name: curvedns Version : 0.87 Upstream Author : CurveDNS developers curve...@on2it.net * URL : http://curvedns.on2it.net/ * License : CurveDNS (retain COPYRIGHT file, public domain) Programming Lang: C, C++ Description : Forwarding implementation of the DNSCurve protocol CurveDNS is the first publicly released forwarding implementation that implements the DNSCurve protocol[0]. DNSCurve uses high-speed high-security elliptic-curve cryptography to drastically improve every dimension of DNS security: * Confidentiality: DNS requests and responses today are completely unencrypted and are broadcast to any attacker who cares to look. DNSCurve encrypts all DNS packets. * Integrity: DNS today uses UDP source-port randomization and TXID randomization to create some speed bumps for blind attackers, but patient attackers and sniffing attackers can easily forge DNS records. DNSCurve cryptographically authenticates all DNS responses, eliminating forged DNS packets. * Availability: DNS today has no protection against denial of service. A sniffing attacker can disable all of your DNS lookups by sending just a few forged packets per second. DNSCurve very quickly recognizes and discards forged packets, so attackers have much more trouble preventing DNS data from getting through. Protection is also needed for SMTP, HTTP, HTTPS, etc., but protecting DNS is the first step. What is so special about this implementation is the fact that any authoritative DNS name server can act as a DNSCurve capable one, without changing anything on your current DNS environment. The only thing a DNS data manager (that is probably you) has to do is to install CurveDNS on a machine, generate a keypair, and update NS type records that were pointing towards your authoritative name server and let them point to this machine running CurveDNS. Indeed, it is that easy to become fully protected against almost any of the currently known DNS flaws, such as active and passive cache poisoning. CurveDNS supports: * Forwarding of regular (non-protected) DNS packets; * Unboxing of DNSCurve queries and forwarding the regular DNS packets * Boxing of regular DNS responses to DNSCurve responses; * Both DNSCurve’s streamlined- and TXT-format; * Caching of shared secrets; * Both UDP and TCP; * Both IPv4 and IPv6. [0] http://www.dnscurve.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#655187: ITP: nacl -- High-speed software library for network communication
Package: wnpp Severity: wishlist Owner: Sergiusz Pawlowicz deb...@pawlowicz.name * Package name: nacl Version : 20110221 Upstream Author : Daniel J. Bernstein d...@cr.yp.to * URL : http://nacl.cace-project.eu/ * License : Public domain Programming Lang: C, C++, Description : High-speed software library for network communication NaCl (pronounced salt) is a new easy-to-use high-speed software library for network communication, encryption, decryption, signatures, etc. NaCl's goal is to provide all of the core operations needed to build higher-level cryptographic tools. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516394: djbdns (was: negative vote for maintainer Michael Gilbert)
On Fri, Jan 6, 2012 at 19:46, Russ Allbery r...@debian.org wrote: Sergiusz Pawlowicz sergi...@pawlowicz.name writes: As dnscache in Debian package is not configured to be run out of the box, security team effectively prohibits the community from using absolutely free, safe and efficient software, as there is no exploits available when you configure it on the loopback interface or for hosts you trust, e.g. for your cloud of services. Well, there aren't *no* exploits; there's still the standard DNS cache poisoning attacks by brute-force port guessing after inducing queries that are inherent in non-DNSSEC and present in every server, and which can be done (with more difficulty) even if you can't query the server directly if you can induce a trusted service to do DNS queries. But that isn't a djbdns-specific problem. Dear Russ, I would like to repeat my statement, this bug, #516394, is not exploitable if your DNS cache is not directly available for an attacker. Because of the design of DNS, I do not propose anyone to make any DNS cache available for any third-parties. But, again, the djbdns Debian package has no such a service from out of the box, and it must be enabled by an administrator. I can prove and admin can configure e.g. httpd to show all your / filesystem tree, does it mean we must remove httpd from Debian? Serge -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516394: [please]
Dear Security Team, Could you please try to forge my DNS cache, the address is: 127.0.0.1, or ::1, if you prefer to attack it through IPv6. Serge -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516394: [CVE-2008-4392]
Dear Security Team, CVE-2008-4392 has Candidate status and is being reviewed for almost three years now, and still must accepted by the CVE Editorial Board[0]. Why, after so many years, Debian Security Team, after a clear statement from prof. Bernstain[1], without confirmation of this rumour from CVE Editorial Board, still blocks djbdns software from the society? Attackers with an access to the network are able to forge DNS responses, and if we treat is as a bug, we must remove all DNS cache software from Debian ASAP. Thanks, Serge [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4392 [1] http://cr.yp.to/djbdns/forgery.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
