Re: Syncing GnuPG between 2 system
Jim Popovitch wrote: > Copying .gnupg is simple and easy, but not quite what I'm looking for. > Imagine having to copy your email folders or address book from system to > system, instead of using something like IMAP. I suppose I could build > something that uses WebDav to sync .gnupg... I was just hoping something > like that existed. you definitely do not want to upload your secret key anywhere. Keep your private key secret and use a keyserver for the public keys. When you have this setup IMAP is not an issue. and BTW no one said that you should copy your mail folder. regards
Re: How to react on a factually wrong Debian wiki change ?
On 2018-09-28, Thomas Schmitt wrote: > Insofar Curt's proposal is technically more correct. > But actually i see no improvement over my shorter statement. > (Maybe it's better english, but it's not better message.) As specified in the part of my article you snipped, the unique purpose of my proposals was to eliminate your unidiomatic phraseology, not to alter or embellish or ameliorate the nature of the message itself. I do think you should probably add your cell phone number to the wiki so that confused users can ring you up if they encounter difficulties. This is being done more and more by developers these days. There's nothing like that "personal touch," Tom, to get those recalcitrant users on board with your software. Good luck and have a good one. Curt > Have a nice day :) > > Thomas > > -- "Now she understood that Anna could not have been in lilac, and that her charm was just that she always stood out against her attire, that her dress could never be noticeable on her." Leo Tolstoy, Anna Karenina
Re: How to react on a factually wrong Debian wiki change ?
On 2018-09-28, Thomas Schmitt wrote: > > This is not "unreliable" it is "clueless". > Insofar Curt's proposal is technically more correct. > But actually i see no improvement over my shorter statement. > (Maybe it's better english, but it's not better message.) I thought nobody said "should better not be used," but sticking that quoted phrase in a search engine produces over 12,000 hits. Doubts now linger in my mind as to whether I haven't used up a lot of electrons for nothing. There's so many of them, though, I guess frugality isn't an issue (unless Wheeler was right, and I've sent the one zipping all over the place). Out. > Have a nice day :) > > Thomas > > -- "Now she understood that Anna could not have been in lilac, and that her charm was just that she always stood out against her attire, that her dress could never be noticeable on her." Leo Tolstoy, Anna Karenina
Re: ncurses problem
On 9/28/18 9:44 AM, Sven Joachim wrote: On 2018-09-27 08:51 -0400, Greg Wooledge wrote: On Wed, Sep 26, 2018 at 10:38:53PM +, Grzesiek Sójka wrote: Hi there, I compiled following test program: == #include #include [snip] It's supposed to show current window dimension when resizing terminal window. Unfortunately, dimensions are not updated and it shows initial geometry. Interesting thing is that it works perfectly after "ssh localhost" or "su -". I tested on both, sid and stretch. exactly the same result. Any ideas?? My first thought is that your shell login profile, PS. I use xfce4 and lxdm. ... which is NOT how you normally log in, is turning on bash's checkwinsize option, which causes bash to set the LINES and COLUMNS variables upon receipt of a SIGWINCH (a signal that is sent when the window changes size). In the absence of that option, those variables might not be set at all, or might be set to the wrong size, and won't be updated when the window changes size while sitting in an idle shell. (What an ncurses program does with this signal, I honestly do not know.) So, just wild-ass guessing here, you might have put the necessaray "shopt -s checkwinsize" and "export LINES COLUMNS" into ~/.profile which is only read when you perform a shell login, and NOT when you perform an lxdm login. Actually it is exactly the other way around. If LINES and COLUMNS are set in the environment, then the ncurses library will _not_ update the screen size upon receiving SIGWINCH, and that causes the behavior Grzesiek observed. This is documented in ncurses(3). It seems that the problem is not related to the environment: # set | egrep 'LINE|COL|BASHOPTS' BASHOPTS=checkwinsize:cmdhist:complete_fullquote:expand_aliases:extquote:force_fignore:hostcomplete:interactive_comments:login_shell:progcomp:promptvars:sourcepath BASH_LINENO=() COLORTERM=truecolor COLUMNS=119 LINES=84 # ssh localhost # set | egrep 'LINE|COL|BASHOPTS' BASHOPTS=checkwinsize:cmdhist:complete_fullquote:expand_aliases:extquote:force_fignore:hostcomplete:interactive_comments:login_shell:progcomp:promptvars:sourcepath BASH_LINENO=() COLUMNS=119 LINES=84 -- Pozdrawiam Grzesiek Wysłane z kompa wolnego od wirusów Billa Gatesa.
Re: ncurses problem
On 2018-09-29 11:02 +, Grzesiek Sójka wrote: > On 9/28/18 9:44 AM, Sven Joachim wrote: >> >> Actually it is exactly the other way around. If LINES and COLUMNS are >> set in the environment, then the ncurses library will _not_ update the >> screen size upon receiving SIGWINCH, and that causes the behavior >> Grzesiek observed. This is documented in ncurses(3). > > It seems that the problem is not related to the environment: > > # set | egrep 'LINE|COL|BASHOPTS' > BASHOPTS=checkwinsize:cmdhist:complete_fullquote:expand_aliases:extquote:force_fignore:hostcomplete:interactive_comments:login_shell:progcomp:promptvars:sourcepath > BASH_LINENO=() > COLORTERM=truecolor > COLUMNS=119 > LINES=84 > # ssh localhost > # set | egrep 'LINE|COL|BASHOPTS' > BASHOPTS=checkwinsize:cmdhist:complete_fullquote:expand_aliases:extquote:force_fignore:hostcomplete:interactive_comments:login_shell:progcomp:promptvars:sourcepath > BASH_LINENO=() > COLUMNS=119 > LINES=84 You need to look at the output of env(1) instead. By default bash does not export LINES and COLUMNS, so they are not visible in child programs: , | % bash | $ echo $LINES | 52 | $ dash | $ echo $LINES | ` Cheers, Sven
Re: How to react on a factually wrong Debian wiki change ?
On 9/29/18 10:59 AM, Curt wrote: > Doubts now linger in my mind as to whether I haven't used up a lot of > electrons > for nothing. > > There's so many of them, though, I guess frugality isn't an issue (unless > Wheeler was right, and I've sent the one zipping all over the place). That's quite some entropy created in our universe. If Carnot is right, we won't get away with it. Cheers. -- Étienne Mollier
Re: ncurses problem
On 9/29/18 9:14 AM, Sven Joachim wrote: On 2018-09-29 11:02 +, Grzesiek Sójka wrote: On 9/28/18 9:44 AM, Sven Joachim wrote: Actually it is exactly the other way around. If LINES and COLUMNS are set in the environment, then the ncurses library will _not_ update the screen size upon receiving SIGWINCH, and that causes the behavior Grzesiek observed. This is documented in ncurses(3). It seems that the problem is not related to the environment: # set | egrep 'LINE|COL|BASHOPTS' BASHOPTS=checkwinsize:cmdhist:complete_fullquote:expand_aliases:extquote:force_fignore:hostcomplete:interactive_comments:login_shell:progcomp:promptvars:sourcepath BASH_LINENO=() COLORTERM=truecolor COLUMNS=119 LINES=84 # ssh localhost # set | egrep 'LINE|COL|BASHOPTS' BASHOPTS=checkwinsize:cmdhist:complete_fullquote:expand_aliases:extquote:force_fignore:hostcomplete:interactive_comments:login_shell:progcomp:promptvars:sourcepath BASH_LINENO=() COLUMNS=119 LINES=84 You need to look at the output of env(1) instead. By default bash does not export LINES and COLUMNS, so they are not visible in child programs: , | % bash | $ echo $LINES | 52 | $ dash | $ echo $LINES | ` Ok, you right. -- Pozdrawiam Grzesiek Wysłane z kompa wolnego od wirusów Billa Gatesa.
Re: Ghostscript produces much larger pdf files now
I recompiled the versions 9.24, 9.23 and 9.22: It changed from 9.22 to 9.23 . Does anyone has an idea what changed here such that the size of the pdf files are bigger? Flo. On 09/28/18 23:54, Flo wrote: > Dear All, > > I am using ghostscript to make pdf files smaller. > > Three days ago I upgraded my system and now I am running 9.25 . However > the size of the pdf files increased significantly. > > I guess a default value changed. Does anyone know about it. I'd like to > have it the way as it worked before. > > Thanks for your hints. > > Flo > > PS: I am using: > gs -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite > -sOutputFile="$outputfile" "$@" > >
Re: How to react on a factually wrong Debian wiki change ?
On Sat, 2018-09-29 at 08:59 +, Curt wrote: > On 2018-09-28, Thomas Schmitt wrote: > > This is not "unreliable" it is "clueless". > > Insofar Curt's proposal is technically more correct. > > But actually i see no improvement over my shorter statement. > > (Maybe it's better english, but it's not better message.) > > I thought nobody said "should better not be used," but sticking that > quoted > phrase in a search engine produces over 12,000 hits. > So 12,000 people can be wrong :) Just altering the word order gives more clarity to the statement. "should be better not used" While still not entirely correct implies less of a threat. "(it) better not be used (or)" - "the computer gods will frot you" "would be better not used" may be correct depending on the rest of the context. Maybe an implicit threat of resulting danger needs to be implied? Cheers Dom. > Doubts now linger in my mind as to whether I haven't used up a lot of > electrons > for nothing. > > There's so many of them, though, I guess frugality isn't an issue > (unless > Wheeler was right, and I've sent the one zipping all over the place). > > Out. > > > Have a nice day :) > > > > Thomas > > > > > >
Re: How to react on a factually wrong Debian wiki change ?
On 2018-09-29, Dominic Knight wrote: > > Maybe an implicit threat of resulting danger needs to be implied? Implicit threats? Yeah, man. Like: "Got money and DVD/BD media to burn? Then burn 'em up with wodim*, the geeky masochist's premier choice for an unspecifiable subset of his burning needs." *Read instructions before use. Harmful if swallowed. > Cheers > Dom. -- "Now she understood that Anna could not have been in lilac, and that her charm was just that she always stood out against her attire, that her dress could never be noticeable on her." Leo Tolstoy, Anna Karenina
Re: Syncing GnuPG between 2 system
On Sat, 2018-09-29 at 09:16 +0200, deloptes wrote: > Jim Popovitch wrote: > > > Copying .gnupg is simple and easy, but not quite what I'm looking > > for. Imagine having to copy your email folders or address book from > > system to system, instead of using something like IMAP. I suppose I > > could build something that uses WebDav to sync .gnupg... I was just > > hoping somethinglike that existed. > > you definitely do not want to upload your secret key anywhere. Well of course not, and that is not what this question is about. ;-) You certainly don't want to sync your email account password either, nor your mothers maiden name. ;-) > Keep your private key secret and use a keyserver for the public keys. > When you have this setup IMAP is not an issue. I get the secret key part. Are you saying to forget about syncing public keys (from other's emails) and just let each client download those from a public keyserver? If so, I may be over thinking the need to sync GnuPG between devices. H. > and BTW no one said that you should copyyour mail folder. I'm the one who brought that up, as an example, because someone (you?) was saying to copy files around from box to box. I mentioned IMAP as an alternative to copying email files/folders, and that I was looking for a similar technique for GnuPG. -Jim P. signature.asc Description: This is a digitally signed message part
Re: Syncing GnuPG between 2 system
On Sat, Sep 29, 2018 at 09:37:43AM -0400, Jim Popovitch wrote: > > I get the secret key part. Are you saying to forget about syncing > public keys (from other's emails) and just let each client download > those from a public keyserver? If so, I may be over thinking the need to > sync GnuPG between devices. H. > If all you care about is the public keys for verifying signatures, then I say don't bother trying to proactively sync. Just let each system get keys and key updates from the public keyservers as needed. Your original message seemed to inidicate that you wanted to both verify signatures and also produce signatures on multiple machines. That was why I provided the link to the article on subkeys, as I consider that to be the only sensible way to have signing capabilities on multitple devices related to a single GnuPG key. Perhaps I misread your email in that regard. Regards, -Roberto -- Roberto C. Sánchez
Re: Syncing GnuPG between 2 system
On Sat, 2018-09-29 at 09:50 -0400, Roberto C. Sánchez wrote: > If all you care about is the public keys for verifying signatures, > then I say don't bother trying to proactively sync. Just let each > system get keys and key updates from the public keyservers as needed. OK, that makes sense, and seems to be the popular opinion. > Your original message seemed to inidicate that you wanted to both > verify signatures and also produce signatures on multiple > machines. That was why I provided the link to the article on subkeys, > as I consider that to be the only sensible way to have signing > capabilities on multitple devices related to a single GnuPG > key. Perhaps I misread your email in that regard. You read my email correctly. I did quickly read and have bookmarked your link. Thank you for that. -Jim P. signature.asc Description: This is a digitally signed message part
libreoffice base - null columns with trigger/default values
Package: libreoffice-base Version: 1:6.1.2-1 Package: libreoffice-sdbc-postgresql Version: 1:6.1.2-1 I have simple form based on postgresql table. In this table there is a column nametype nullable default value utw timestamp without time zone not null now() This column does not have its field in form. Recently (after upgrade?) I cannot save filled form to database, because "required utw field has no value" When I drop "not null" from column, and restart libreoffice - form could be saved to database. Should I fill a bug? KJ -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html Martin was probably ripping them off. That's some family, isn't it? Incest, prostitution, fanaticism, software. -- Charles Willeford, "Miami Blues"
Re: libreoffice base - null columns with trigger/default values
kjo...@poczta.onet.pl (Kamil Jońca) writes: > Package: libreoffice-base > Version: 1:6.1.2-1 > > Package: libreoffice-sdbc-postgresql > Version: 1:6.1.2-1 > > I have simple form based on postgresql table. > In this table there is a column > > nametype nullable default > value > utw timestamp without time zone not null now() > > This column does not have its field in form. > Recently (after upgrade?) I cannot save filled form to database, because > "required utw field has no value" > > When I drop "not null" from column, and restart libreoffice - form could > be saved to database. I tried with version: 1:6.1.1~rc1-2 of libreoffice packages and its works as expected. KJ -- http://wolnelektury.pl/wesprzyj/teraz/ That's what she said.
Re: How to react on a factually wrong Debian wiki change ?
On 9/29/18, Dominic Knight wrote: > On Sat, 2018-09-29 at 08:59 +, Curt wrote: >> On 2018-09-28, Thomas Schmitt wrote: >> > This is not "unreliable" it is "clueless". >> > Insofar Curt's proposal is technically more correct. >> > But actually i see no improvement over my shorter statement. >> > (Maybe it's better english, but it's not better message.) >> >> I thought nobody said "should better not be used," but sticking that >> quoted >> phrase in a search engine produces over 12,000 hits. >> > So 12,000 people can be wrong :) > > Just altering the word order gives more clarity to the statement. > > "should be better not used" While still not entirely correct implies > less of a threat. > > "(it) better not be used (or)" - "the computer gods will frot you" > > "would be better not used" may be correct depending on the rest of the > context. > > Maybe an implicit threat of resulting danger needs to be implied? Wodim should not be used for burning to DVD or BD media. Which also implies no support for DVD/BD burning. And link "should not be used" to https://lists.debian.org/debian-user/2018/09/msg01048.html to explain why it should not be used? Regards, Lee
Re: Syncing GnuPG between 2 system
Jim Popovitch wrote: > On Sat, 2018-09-29 at 09:50 -0400, Roberto C. Sánchez wrote: >> If all you care about is the public keys for verifying signatures, >> then I say don't bother trying to proactively sync. Just let each >> system get keys and key updates from the public keyservers as needed. > > OK, that makes sense, and seems to be the popular opinion. > >> Your original message seemed to inidicate that you wanted to both >> verify signatures and also produce signatures on multiple >> machines. That was why I provided the link to the article on subkeys, >> as I consider that to be the only sensible way to have signing >> capabilities on multitple devices related to a single GnuPG >> key. Perhaps I misread your email in that regard. > > > You read my email correctly. I did quickly read and have bookmarked > your link. Thank you for that. > IMO you sign based on the e-mail you use. IMO it is confusing with multiple machines. A key is associated with identity -> the email. With the sub keys you can add more identities. Still to encrypt you need the private key. It is sufficient to update the private key on the other machines. You usually do not copy it over internet connection. Some people use secure key cards, other encrypted usb sticks or md/sd whatever cards. the public keys are uploaded to the key server after updated (for example signed by you) and downloaded/updated on the other machines when needed. It is up to you to decide how you handle your security. It is a sensitive topic, so general reading and understanding of the matter is required, before proceeding in real life. regards
Where is xfce.org?
What has happened to xfce.org? It seems to have disappeared and left no tracks.
Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ???
On Thu, 27 Sep 2018 17:54:26 +1000 Andrew McGlashan wrote: ... > The biggest weakness with the Dropbear setup is that the initramfs is > stored on an unencrypted partition (no matter which file system is > used). That means that someone with physical access can rebuild the > initramfs and include their own key as well as other stuff to > compromise the security of the server. > > Aside from the fact that the IME is suspect, it would be great if grub > can be, somehow, given a method that allows for full disk encryption > which will include everything in /boot -- especially initramfs. But grub itself and its configuration can't be encrypted, so an attacker could still compromise that code / data. IIUC, your solution basically just implies moving some of the logic currently in the initramfs into grub. One solution is to run grub from removable media, and preventing attackers from getting physical access to it ... Disclaimer: I'm no expert, and am just expressing my understanding of the underlying unsolvable problem based on what I've read about it. Celejar
Re: Where is xfce.org?
On 2018-09-29 at 21:06, Dennis Wicks wrote: > What has happened to xfce.org? > It seems to have disappeared and left no tracks. There's apparently an announcement on Reddit about it: https://www.reddit.com/r/xfce/comments/9jvh2b/xfceorg_is_down_due_to_hosting_issues/ I'd done a fair bit of independent investigation, before going looking for further discussion elsewhere, and finding this. Based on that investigation, it seems likely that it could be DNS registration expired, hosting provider (apparently the University of Namur, formerly Facultes Universitaires Notre-Dame de la Paix) no longer providing, or some combination of both. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Ghostscript produces much larger pdf files now
On Sat, Sep 29, 2018 at 8:01 AM Flo wrote: > > I recompiled the versions 9.24, 9.23 and 9.22: > It changed from 9.22 to 9.23 . Does anyone has an idea what changed here > such that the size of the pdf files are bigger? > > Flo. I do not know much about ghostscript pdf conversion. But the information you have given so far is not enough to reproduce the issue. I see that you have already given the command you are using. Please provide a sample input file, and sample output files. What is the increase in size of the pdf files produced with different versions you tried? -- Kamaraju S Kusumanchi | http://raju.shoutwiki.com/wiki/Blog
Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ???
Celejar wrote: > But grub itself and its configuration can't be encrypted, so an > attacker could still compromise that code / data. IIUC, your solution > basically just implies moving some of the logic currently in the > initramfs into grub. > Yes, this is the point I am making. > One solution is to run grub from removable media, and preventing > attackers from getting physical access to it ... > But this does not apply for a server, where you do not have physical access, however in this case it is also obvious that no one can easily access the machine and alter anything on it, except it is stolen. > Disclaimer: I'm no expert, and am just expressing my understanding of > the underlying unsolvable problem based on what I've read about it. so do I
