Re: discussing upstream software on -devel (Re: Bug#614601: ITP: libsafewrite -- Simple functions for performing safe atomic replacement of files
2011/2/25 Shachar Shemesh shac...@debian.org: and I have been warned by the list masters that discussing a specific package's upstream bugs on Debian-devel is off topic. I dont think this is neither true nor what they said. Surely a discussion about upstream bugs can become off-topic on debian-devel though. I agree with Holger - this thread went rapidly off-topic. I'm sorry, Neil, but I'm quoting your message almost in full. Neil Williams sent me the following on January 3rd, regarding the previous thread about safewrite: I'm not a listmaster, I made no claim to be a listmaster. Please remember,debian-devel@lists.debian.org is for discussion between Debian developers about issues within Debian (like problems within groups of packages or with particular tools), it's not intended for individual source code project development. This issue is general filesystem/programming issues, it is not Debian specific. Please can you find / setup a list for this project and move the discussion elsewhere from here on? If you want to keep it within the realm of source code related to Debian, an Alioth mailing list would be better. That is also still true. There comes a point where an Alioth mailing list is the place for these discussions. IMHO the original thread got to that point long before I actually bothered to reply. In future I won't bother, I'll just kill the entire thread. To which I replied that I cannot terminate an already running thread You could at least have setup the list, CC'd the list on each reply and asked people to use it. None of those things happened. , and the setting up a mailing list for a project which is likely to reach maturity in a couple of versions is a bit of a waste Pointless procrastination. One extra quiet mailing list on Alioth is no burden. I've got about six which might become useful again in the future. , but that I'll try to wind down the discussion thread. I'm assuming that his lack of response indicates that he found my answer satisfactory. A lack of reply is no indication of anything. It does not indicate my satisfaction, it merely indicates that I didn't get around to writing a reply as I had more useful things to do off-list which directly relate to Debian development. On that topic, I'm going to go back to useful work and once again mark this thread - and possibly all future posts related to this software - as junk. If you wish to try to prolong the pain, I may find it necessary to apply the same mark to all email from you. Please find something more useful to do. -- Neil Williams = http://www.linux.codehelp.co.uk/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTinPNoE79VYDvxFsmT6W=rjh2d05yrdgou47a...@mail.gmail.com
Re: discussing upstream software on -devel (Re: Bug#614601: ITP: libsafewrite -- Simple functions for performing safe atomic replacement of files
On 23/02/11 12:23, Holger Levsen wrote: Hi, On Mittwoch, 23. Februar 2011, Shachar Shemesh wrote: Giving feedback over the upstream trustworthiness is not the purpose of ITP bugs, oh, hell yes, it is. Where else should we discuss what software fits into Debian? debian-qa@ when it's too late? Sorry. I phrased it wrong. I committed a largish change to git and then tested when I had the chance (a few days later). Upon testing, I used the wrong variable in a couple of places, which obviously caused things to not work. I committed this with the log message Fix bugs a few small bugs. Redundant word aside, the word small is what brought The Wrath of Ben on my head. Don't get me wrong. After the initial instinct to flame subsided, I didn't mind that much. I got a bunch of comments, about 50% of which were actually useful to some degree (all of which are already fixed), and I learned something about the Linux kernel that I didn't before. If a maintainer's decision to relate to the size of the fix rather than the size of the consequence is a reason to boycott a package from Debian, then do let me know, because as things stand I intend to continue with the submitting process. and I have been warned by the list masters that discussing a specific package's upstream bugs on Debian-devel is off topic. I dont think this is neither true nor what they said. Surely a discussion about upstream bugs can become off-topic on debian-devel though. I'm sorry, Neil, but I'm quoting your message almost in full. Neil Williams sent me the following on January 3rd, regarding the previous thread about safewrite: Please remember,debian-devel@lists.debian.org is for discussion between Debian developers about issues within Debian (like problems within groups of packages or with particular tools), it's not intended for individual source code project development. This issue is general filesystem/programming issues, it is not Debian specific. Please can you find / setup a list for this project and move the discussion elsewhere from here on? If you want to keep it within the realm of source code related to Debian, an Alioth mailing list would be better. To which I replied that I cannot terminate an already running thread, and the setting up a mailing list for a project which is likely to reach maturity in a couple of versions is a bit of a waste, but that I'll try to wind down the discussion thread. I'm assuming that his lack of response indicates that he found my answer satisfactory. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d675de4.4050...@debian.org
discussing upstream software on -devel (Re: Bug#614601: ITP: libsafewrite -- Simple functions for performing safe atomic replacement of files
Hi, On Mittwoch, 23. Februar 2011, Shachar Shemesh wrote: Giving feedback over the upstream trustworthiness is not the purpose of ITP bugs, oh, hell yes, it is. Where else should we discuss what software fits into Debian? debian-qa@ when it's too late? and I have been warned by the list masters that discussing a specific package's upstream bugs on Debian-devel is off topic. I dont think this is neither true nor what they said. Surely a discussion about upstream bugs can become off-topic on debian-devel though. cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#614601: ITP: libsafewrite -- Simple functions for performing safe atomic replacement of files
Package: wnpp Severity: wishlist Owner: Shachar Shemesh shac...@debian.org * Package name: libsafewrite Version : 1.00 Upstream Author : Shachar Shemesh shac...@lingnu.com * URL : http://www.lingnu.com/opensource/safewrite.html * License : MIT Programming Lang: C Description : Simple functions for performing safe atomic file updates Safewrite is a library for simple, almost drop-in replacement to the usual open and close calls. Using safewrite, however, guarantees that the files be updated in an atomic way - anyone trying to read the file is guaranteed to get a complete version, either the old or the new, but never a partially updated file. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110222144115.9844.58744.report...@dellosun.office.lingnu.com
Re: Bug#614601: ITP: libsafewrite -- Simple functions for performing safe atomic replacement of files
On Tue, Feb 22, 2011 at 04:41:15PM +0200, Shachar Shemesh wrote: Package: wnpp Severity: wishlist Owner: Shachar Shemesh shac...@debian.org * Package name: libsafewrite Version : 1.00 Upstream Author : Shachar Shemesh shac...@lingnu.com * URL : http://www.lingnu.com/opensource/safewrite.html * License : MIT Programming Lang: C Description : Simple functions for performing safe atomic file updates Safewrite is a library for simple, almost drop-in replacement to the usual open and close calls. Using safewrite, however, guarantees that the files be updated in an atomic way - anyone trying to read the file is guaranteed to get a complete version, either the old or the new, but never a partially updated file. Judging by what you consider 'small bugs' in https://github.com/Shachar/safewrite/commit/efafcd4260375a41257709c7eb5a8d6065366849 why should anyone trust their important data to this library? I quickly reviewed the code and found: safe_open() might not return correct error codes, since the library and system calls in its cleanup code may overwrite the original error code. It uses a fixed extension for the temporary file name, and unlinks whatever was there before; this could be a security flaw. It doesn't check for failure of fstat() (this is unlikely but possible, e.g. when using a network filesystem). Copying setuid and setgid bits to an empty file is pointless, since they are cleared by write() (this is a good thing!). safe_close() doesn't actually close the file or free the 'context' if fsync() fails. This is inconsistent with close(). Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110222175450.gk28...@decadent.org.uk
Re: Bug#614601: ITP: libsafewrite -- Simple functions for performing safe atomic replacement of files
On 22/02/11 19:54, Ben Hutchings wrote: Judging by what you consider 'small bugs' in https://github.com/Shachar/safewrite/commit/efafcd4260375a41257709c7eb5a8d6065366849 why should anyone trust their important data to this library? Feel free not to use it/file bugs against it. Giving feedback over the upstream trustworthiness is not the purpose of ITP bugs, and I have been warned by the list masters that discussing a specific package's upstream bugs on Debian-devel is off topic. I quickly reviewed the code and found: Did you read the accompanying manual pages first? safe_open() might not return correct error codes, since the library and system calls in its cleanup code may overwrite the original error code. Thank you for your input. I'll fix it. It uses a fixed extension for the temporary file name, and unlinks whatever was there before; this could be a security flaw. The matter has been discussed before. If you have a specific scenario where this will cause a security flaw, please feel free to file a bug or contact me directly. Pending that happening, my analysis is that there is no security flaw in that case. It doesn't check for failure of fstat() (this is unlikely but possible, e.g. when using a network filesystem). Interesting point. I'll have to think about it. Copying setuid and setgid bits to an empty file is pointless, since they are cleared by write() (this is a good thing!). Frankly, I was not aware of this. I could not find it documented in the man pages. In any case, this is no regression from the non-safe_open case, as these would get cleared on write either way. If this is a Linux only feature, I'm actually inclined to leave the code in (which is why I needed the manual pages). safe_close() doesn't actually close the file or free the 'context' if fsync() fails. This is inconsistent with close(). But consistent with what the man page says about it. The alternative is to not allow the user to retry saving the file's content, which I don't see as preferable. Thank you for your feedback. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d648429.5010...@debian.org
Re: libsafewrite
On Mon, Jan 3, 2011 at 12:53 PM, Shachar Shemesh shac...@debian.org wrote: Where are the regressions vs the non-atomic variant listed? nowhere, yet. It's not released. That's one of the more interesting parts. Does it destroy ACLs? Didn't see any code to preserve them. Olaf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinmlrjqupuuwy0mmdnka5ebvh4tkwehh_os2...@mail.gmail.com
Re: libsafewrite
On 03/01/11 14:54, Olaf van der Spek wrote: That's one of the more interesting parts. It sure is to you. I'm not sure about other users. I'll tell you what - I'll make the project's home page a wiki, and you can document these to your heart's content. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d21d64d.3070...@debian.org
Re: libsafewrite
On Mon, Jan 3, 2011 at 2:59 PM, Shachar Shemesh shac...@debian.org wrote: On 03/01/11 14:54, Olaf van der Spek wrote: That's one of the more interesting parts. It sure is to you. I'm not sure about other users. I'll tell you what - I'll Doesn't the Debian project care about regressions (and quality in general)? make the project's home page a wiki, and you can document these to your heart's content. Cool -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinp51yxr-bjpiur7-vrdhw9dzxnduy8c=37m...@mail.gmail.com
Re: libsafewrite
On 03/01/11 16:05, Olaf van der Spek wrote: Doesn't the Debian project care about regressions (and quality in general)? I'm sorry, but from scanning the conversation so far, no one but you seems to regard this as either a regression or a loss of quality. I will shut up at this point to let anyone who disagrees with this statement come forward and say so. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d21d87f.5020...@debian.org
libsafewrite
On Mon, Jan 3, 2011 at 11:35 AM, Shachar Shemesh shac...@debian.org wrote: BTW - feedback welcome. Where are the regressions vs the non-atomic variant listed? Olaf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=iecturkh=rmhgkkxdojmft1jkwj_jtyva7...@mail.gmail.com
