Simon Josefsson <simon <at> josefsson.org> writes: > > Yes, because of the GNU philosophy of avoiding arbitrary limits (including a > >>2gb file that getpass happens to be reading from). > > I didn't follow the discussions regarding fseek*, but will using 'fseek > (out, 0, SEEK_CUR);' instead of fseek really break anything?
Yes. If getpass.c is compiled on a platform that lacks /dev/tty support and which has 32-bit long but 64-bit off_t, and is given stdout as a seekable file bigger than 2gb, then the fseek is required to fail with EOVERFLOW while fseeko will correctly reposition the file. On platforms with /dev/tty support, plain fseek should be okay (since ttys are non-seekable, both fseek and fseeko are likely no-ops that fail with ESPIPE, although POSIX leaves the behavior of fseek on a tty undefined). > Btw, the error value from fseeko is not checked. Would it make sense to > avoid printing \n if fseeko failed? On platforms with /dev/tty support, it is likely that fseek[o] always fails because ttys are not seekable. So checking for fseek[o] error isn't really going to do the getpass module any good. Rather, the point of the fseeko is the side effect of safely switching from reading to writing on an updateable stream, which should happen even if the fseeko failed. > Printing the \n when fseeko may > lead to revealing the password, if I understand the comment correctly > (and if the comment is in fact correct). I don't think this is an issue in the getpass code. > > /Simon > > -- Eric Blake
