Re: DD Ping: please review proxytunnel
On Sat, May 02, 2020 at 07:07:34PM +0200, Sven Geuer wrote: > Hello Julian, > > any feedback from your side is equally very welcome. > > Cheers, > Sven Hello Sven, I'm so sorry - I have been completely swamped by work, and haven't had time to look at this for you :-( Thanks so much for doing all this work! Best wishes, Julian
Re: Maintaing proxytunnel through the team
On Wed, Apr 22, 2020 at 08:52:19PM +0200, Sven Geuer wrote: > Hi Samuel, Julian and Marco > > Regarding > >But I agree that the '.1.' is excessive (even though I have been > > guilty of it myself - I was just copying what someone else had done > > and presumed that it had a good reason...). > > The '.1.' helps to keep the version numbers monotonically increasing if > there should be another version for the same date. For instance > > 1.2.3+git20200422.ef8a32b > 1.2.3+git20200422.2193ffa > > is not monotonically increasing, but one enforces it this way > > 1.2.3+git20200422.1.ef8a32b > 1.2.3+git20200422.2.2193ffa > > I agree you will really need this quite rarely. While the commit > fingerprint is a must as it serves to uniquely identify a commit. Rare indeed! You can always wait <24 hours and then upload a new version instead ;-) Best wishes, Julian
Re: Maintaing proxytunnel through the team
On Wed, Apr 22, 2020 at 07:17:28PM +0200, Marcos Fouces wrote: > > > If you add some more commits, you can add them as patches in > > > d/patches > > > and refer it in d/changelog. > > > > Or just release a new version? Or do you mean cherry-picking later > > commits? > > > > Yes, you can cherry-pick all the commits you want and add them to > d/patches. I am thinking about forks on Github that could also contains > interestings commits. > > This kind of situation would be near to imposible to reflect this way. Yes, indeed; I wasn't imagining trying to contain that information in the version number. I was thinking of keeping the short commit id in the upstream version number to help identify the commit that is stored in the .orig.tar; everything in the d/patches is applied to that commit. Best wishes, Julian
Re: Maintaing proxytunnel through the team
On Wed, Apr 22, 2020 at 03:09:16PM +0200, Marcos Fouces wrote: > Hi Julian and Samuel > > I found that there is 1493 binary packages that use the "git" string in > the release number. There is some exotic variations (like this one > 0.0~GOTK3~0~2~0+git20170418.0.96d4110-3) > > I believe that ".1." refered by Samuel could be considered as a kind of > an epoch. This is useful because the characters of the commit cannot be > used to sort releases. > > IMHO, there is no strong need to insert the date, some characters of > commit id, a custom epoch... Using "git+date" should be enough in most > cases. Hi Marcos, I have found that having a commit id in the package version can be helpful: - sometimes there is more than one upstream commit in a day - sometimes the commit date is somewhat ambiguous, especially if the commit was on a different branch and then merged into the master branch at a later date - what is the date that should then be used? Different maintainers have used different choices, but the commit id is unambiguous. These have arisen when I've been trying to compare a Debian package to the upstream original to track down some issue or other. But I agree that the '.1.' is excessive (even though I have been guilty of it myself - I was just copying what someone else had done and presumed that it had a good reason...). > If you add some more commits, you can add them as patches in d/patches > and refer it in d/changelog. Or just release a new version? Or do you mean cherry-picking later commits? Best wishes, Julian
Re: Maintaing proxytunnel through the team
On Wed, Apr 22, 2020 at 01:34:32AM +0100, Samuel Henrique wrote: > Hello Sven, > > I believe the package is a fit for our team yes. > > The repository is created at > https://salsa.debian.org/pkg-security-team/proxytunnel > But before the push I'd like to ask you about the latest upstream > release imported: 1.9.1+git20200123.1.eff4d41 > > What's up with the "1.eff4d41" part? I didn't investigate but I assume > the last one is part of the git commit hash, but I don't know about > the ".1.". > I feel like I'm missing something, generally I prefer to use only a > date for tarballs coming from git snapshots, and I believe they are > more clean, though I recognize it's not as precise as having the > commit id. Hello Samuel, There is no particular consensus for git-based version numbers. egrep 'Package:|Version:' /var/lib/apt/lists/ftp.uk.debian.org_debian_dists_testing_main_binary-amd64_Packages | grep -B 1 '+git' | less shows a wide variety. But it is very common to include the first 7 characters of the commit id. Best wishes, Julian
Re: [SECURITY] [DSA 3053-1] openssl security update
On Thu, Oct 16, 2014 at 05:48:24PM +0200, Thijs Kinkhorst wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - - Debian Security Advisory DSA-3053-1 secur...@debian.org http://www.debian.org/security/ Thijs Kinkhorst October 16, 2014 http://www.debian.org/security/faq - - Package: openssl CVE ID : CVE-2014-3513 CVE-2014-3566 CVE-2014-3567 CVE-2014-3568 [...] Now that the jessie release is well underway, is it possible either to request unblocks for security uploads or to begin to support a jessie/testing suite in security.debian.org? Thanks, Julian -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141018210811.ga8...@d-and-j.net
Re: 'export RESOLV_HOST_CONF= any file you want' local vulnerability
On Mon, Jan 08, 2001 at 05:57:23PM +, thomas lakofski wrote: Since I've not had any response yet, I thought I'd give a demonstration of how nasty this is: Script started on Mon Jan 8 17:48:23 2001 [EMAIL PROTECTED]:~$ export RESOLV_HOST_CONF=/etc/shadow [EMAIL PROTECTED]:~$ ping localhost PING localhost (127.0.0.1): 56 data bytes --- localhost ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss [EMAIL PROTECTED]:~$ fping localhost /etc/shadow: line 1: bad command `root:censored:11063:0:9:7:::' [snip] Most weird. I get this behaviour when running through a setuid root strace, but I don't get the error messages (and hence the content of /etc/shadow) when I don't use strace. I'm still running potato. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
