Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 )
On Thu, Sep 07, 2017 at 10:50:00PM +0100, Michael Grant wrote: > Nifty, been a while since I used the LD_PRELOAD trick myself. > > This whole thing has been bothering me over the last couple days. Why > are so few people having this issue? There are few that are running servers on Debian testing. Most are running desktops. The most popular program on desktop is a browser, and I know no popular GUI browser that's using openssl for cryptography. Imagine, for instance if Mozilla said "we're dropping support of anything except TLS1.2". Now *that* would produce a real dungstorm here. > Did this or will this patch get into Stretch Stable yet as a security > patch? If yes, then won't there be hundreds if not thousands of > people screaming about this? Highly unlikely. Debian stable is called "stable" because they don't change behavior of binaries and libraries like that *unless* there is a compelling reason. Like, for instance, a grave zero-day bug that upstream fixes in the most recent version only and the fix is impossible to backport to a current stable Debian package. Exactly this happened to samba last year. I suppose they could disable "anything but TLS1.2 by default" in stable's openssl *if* someone manage to show a series of unfixable security bugs in TLS1.1 (already happened for SSL3.0 and TLS1.0). > But what's going to happen if there is some other security fix which > is needed in Stretch's libssl1.1 (1.1.0f-3)? Will there be some fork > of this library for Stretch without this patch? Or will at that time > this patch get swept in with some other future security patch and the > hit the wild with Stretch stable + security patches? See above. > By pinning this library at 1.1.0f-3 on my system, I feel somehow I've > done the wrong thing. I started to think I should put in Reco's hack > until these Windows 7 and Mac 10.11 users move to more modern releases > or MS and Apple send out patches for their older stuff. No, it won't work that way. First, this LD_PRELOAD library does exactly one thing - it downgrades default TLS version to TLS1.0. If your users have the trouble connecting to your mailserver because their clients cannot do TLS1.2 and that's the only thing your mailserver advertizes - your users still won't be able to connect after downgrading *their* end to TLS1.0. Second, I somehow doubt that your users' MUAs are based on openssl. Third, since then LD_PRELOAD works on Windows? What you *can* do with this library is to deploy it on your *server* and LD_PRELOAD cirrus/dovecot/exim/postfix/whatever you have there. It may even work (I haven't tried it though). > Or maybe I > should follow Stretch (and it's security fixes) for only this package > instead of pinning it to this version. This approach will buy you some time, but …… sooner or later Debian maintainer decides to migrate to openssl 1.2. Or introduce an incompatible ABI change in openssl 1.1 - OpenSSL upstream in (in)famous for that. Then they will rebuild the whole main and contrib archive and your pinning will cease to do anything meaningful. > And by the way, this isn't just limited to mail clients. It's also > affecting MTAs. I see a large number of mail servers connecting to my > server that only do TLSv1 and TLSv1.1. When they can't do TLS, I > think they just fall back to SMTP in the clear. So the problem isn't > obvious to any user and mail in general is just less secure. > > In doing some reading about TLS and it's problems, there are problems > with TLSv1 and I understand those were fixed in Debian's libssl1. > TlSv1.1 had some problems but were more minor and the move to 1.2 > seemed more about enhancing security versus some removing design > flaws. Clearly the vendors like Microsoft and Apple did not think it > critical to move away from TLSv1 and TLS1.1 and probably patched it > like Debian. Hence they consider their versions of TLSv1 and TLSv1.1 > safe enough. > > While I am totally sympathetic to getting the world onto TLSv1.2 and > greater, this seems like a support disaster waiting to happen. > > What is the right way for an admin to handle this problem on Debian Testing? The only thing they told me back in the day was 'if you have to do a server - you use Debian stable'. This openssl incident and may others only prove this principle right. Reco
Re: Editor survival [Was: Recommended editor for novice programmers?]
If you are torn between emacs and vi, it's probably because you haven't run eval-mode inside emacs. On Fri, 8 Sep 2017, Nick Boyce wrote: Date: Thu, 7 Sep 2017 22:19:49 From: Nick Boyce To: debian-user@lists.debian.org Subject: Re: Editor survival [Was: Recommended editor for novice programmers?] Resent-Date: Fri, 8 Sep 2017 02:18:59 + (UTC) Resent-From: debian-user@lists.debian.org On Wed, 6 Sep 2017 16:08:15 +1000 Erik Christiansen wrote: On 06.09.17 05:31, Nick Boyce wrote: [...] [Joe is] one of the first things I install on any Linux or *BSD system. In my decades of leading software teams, one thing I did not do is ask "What editor do you use?", even in employment interviews. In my experience, a programmer is most productive using the editor with which he's most proficient. You're absolutely right. I have sat next to seasoned vi users watching in awe as their fingers flew entering weird totally non-intuitive commands (to me) and achieving great edits in next to no time. Other colleagues lived inside emacs all day long, using it as a sort of OS with an editor attached. I used other editors to achieve the same goals, quite possibly taking more real time than the vi guys. Each to their own. It's interesting how programmers who arrived at Unix via VMS, and programmers who came from the mainframe world, often have correspondingly different software tastes. ... and vi's power makes light work of many tasks but it's as user-friendly as a cornered rat On the three occasions I've had to extract a marsupial possum from our chimney (they're like a cat on steroids), I've armed myself with thick leather gloves and grim determination. :) For vim, a cheat-sheet suffices, and :help " or google do explain. On DEC Ultrix, Digital Unix (OSF/1 .. Tru64) and on HPUX there is no vim, and the DEC/HP salesmen have delivered no cheet sheets with the beasts, and in vi the F1 key does not summon any help, and from insert mode there is no help command, and in 1995 google has not yet been invented. The unskilled novice smokes a cigarette (it's 1995) to calm down, and gravitates to a different editor ... a whole bunch of weird character sequences get entered instead of cursor control, which you then spend the next 10 minutes removing again. Ugh. That's an xterm error, as the arrows simply produce motion even in Insert-mode, if that's properly set up. Agreed .. or whatever terminal (emulation) you're actually using - in my case very often a real VT220/320/420, attached to a VMS, then TELNETed to a Un*x, where the available /etc/termcap|terminfo may or may not have been well crafted back at the factory. Sometimes an ICL mainframe VDU connected via an obscure 3rd-party emulation converter box to a DEC machine. Latterly it would be some 3rd-party terminal emulator on Windows 3.1/95. I still say ugh, though it may well not be vi's fault. The fact is that miraculously 'joe' seemed to be much more resilient and usable in these circumstances. As did emacs .. if you could afford to wait. I like an editor to appear within 1 second of me calling it (which rules out most GUI editors). ... unless you also add something like: " These days I expect to be out of insert mode, after a vertical move: inoremap ^[ inoremap ^[ That's great to have - thanks for that (seriously), along with the other .vimrc tweaks you gave. I realise much can be improved by tweaking .vimrc, as it can be with .muttrc, .bashrc and the like. This is why power users often carry their own personal versions of these rc files with them wherever they roam ... and old greybeards sometimes dispense rc nuggets to neophytes at moments of crisis. Cheers Nick --
Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 )
Michael Grant wrote: > Nifty, been a while since I used the LD_PRELOAD trick myself. > This whole thing has been bothering me over the last couple days. Why > are so few people having this issue? 18 or so posts on this, only 3 > or so of us have done anything about this. I backed out libssl (and > pinned it). Reco makes a LD_PRELOAD hack. Sven recompiles OpenSSL > with patch removed. > Did this or will this patch get into Stretch Stable yet as a security > patch? If yes, then won't there be hundreds if not thousands of > people screaming about this? No, it won't. > I am wondering why it's so few of us who seem to be affected? I > suspect it's because 1) we're running Debian Testing and most of the > Debian world runs Stable, 2) more and more people are turning to gmail > and outlook.com instead of running their own mail servers and 3) the > few remaining people who do go to the trouble of using Debian Testing > as a mail server probably wouldn't care that much about getting TLS > set up with imap/pop/smtp working at all. Probably. > If this patch won't go to Stretch as a security fix, then the world is > hidden from this until Buster comes out in about 2 years. Exactly. Read the discussion(s) in debian-devel about this. The last idea was to have Buster semi-broken until shortly before the release and then switch back on TLS1.0 and TLS1.1 support. > But what's going to happen if there is some other security fix which > is needed in Stretch's libssl1.1 (1.1.0f-3)? Will there be some fork > of this library for Stretch without this patch? Or will at that time > this patch get swept in with some other future security patch and the > hit the wild with Stretch stable + security patches? Since this patch is a Debian-only change and in no way included in upstream in any way, a security update for Stretch will not contain this change. > By pinning this library at 1.1.0f-3 on my system, I feel somehow I've > done the wrong thing. We all habe done the wrong thing by diverting from the main development path of Buster. > I started to think I should put in Reco's hack until these Windows 7 > and Mac 10.11 users move to more modern releases or MS and Apple send > out patches for their older stuff. Or maybe I should follow Stretch > (and it's security fixes) for only this package instead of pinning it > to this version. Pinning this package to Stretch will not work very long, I think. At some point Stretch and Buster will have diverged to far for the library from Stretch being compatible with the rest of Buster. > And by the way, this isn't just limited to mail clients. It's also > affecting MTAs. I see a large number of mail servers connecting to my > server that only do TLSv1 and TLSv1.1. When they can't do TLS, I > think they just fall back to SMTP in the clear. So the problem isn't > obvious to any user and mail in general is just less secure. It is far more problematic for WLAN+freeradius. Currently ~50% of Android phones can't use TLS1.2 for the SSL handshake during the EAP phase of the WPA-Enterprise login. Also Windows 7 and Windows 8/8.1 are unable to connect because of the same problem. > While I am totally sympathetic to getting the world onto TLSv1.2 and > greater, this seems like a support disaster waiting to happen. Oh yes, absolutley. I admin many servers and infrastructure in an University network and if this change happens to be included in Buster, I will either have to recompile OpenSSL forever, backing out the change, or, more likely, switch all systems to a different distribution, probably CentOS. I can't just tell the majority of my students to get a new phone or laptop because some Developer thaught he could pressure the world to rotate in a different direction by decree. In two years when Buster is release, adoption of TLS1.2-only will not be high enough to just switch off everything else. > What is the right way for an admin to handle this problem on Debian Testing? Don't use Debian Testing on production systems. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 )
Reco wrote: > On Thu, Sep 07, 2017 at 10:50:00PM +0100, Michael Grant wrote: >> What is the right way for an admin to handle this problem on Debian >> Testing? > The only thing they told me back in the day was 'if you have to do a > server - you use Debian stable'. This openssl incident and may others > only prove this principle right. Exactly. I have my home and personal systems on Unstable+Experimental, but only because a) I am adventurous, b) have been doing this for a very long time an know how to get myself out of any mess and c) I am the only one using this and if something breaks I don't harm anyone else. S° -- Sigmentation fault. Core dumped.
Re: unable to determine which package my bug report should be filed against - please advise.
On Thu, 07 Sep 2017 16:51:25 -0400 DM wrote: > Hello Debian support team. I am a happy Dabian 9 user. I would like > to report an issue I am experiencing. In the past I used a package > 'reportbug' to report bugs, but by design, I have to identify what > package the issue is related to. > > I am not sure exactly what may be the cause of the issue, and I am > reaching out to you for help to identify what part of Debain might be > causing this issue. > > The issue: I am using a second monitor (external monitor connected > via a displayport - LG 29UM57-P). External monitor connected to my > laptop - Lenovo T420. External monitor does not display video at the > desired resolution and the aspect ratio. > > Displayed resolution - 1920 x 1080 > Displayed aspect ratio - 16:9 > > Expected resolution - 2560 x 1080 > Expected ratio - 21:9 > > This same exact issue exist on my other machine Lenovo X230 with > external monitor of exact same model. > > Previous version of Debian 8 (jessie) worked with out any issue with > the monitor at the correct and expected resolution and the aspect > ratio. > > After installing a fresh version of Debian 9 (Stretch), I am unable > to use the external monitor at its maximum resolution. Debian 9 > (Stretch) was a full installation from scratch (not an upgrade). > > All cables has been tested, and hardware issues has been ruled out. > > I am not sure if I should be filing a bug report identifying Gnome3, > or X11 as a cause of the issue or some other part of the OS. > > Could you please advise. > It saves a bit of time if you can identify the correct package, and it's often obvious, but it's not crucial to do so. Make your best guess and report the bug. If you're wrong, the Developer God will roll his eyes, mutter 'idiot', and reassign it to the correct package, though sometimes bugs get worked on significantly before the correct package can be identified. The important thing is to get it logged into the system. 'Gnome' is the wrong guess, as it's just a gigantic collection of somewhat-related packages, I'd go for xserver-xorg, itself a collection of packages, but a much smaller one, and it will cause all the X-related packages to be listed in the bug report. 'Gnome' would give you a bug report the size of an old-style telephone directory. You'll probably be asked to supply further information, by someone who knows what they want to see and where to find it. -- Joe
Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 )
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Sep 07, 2017 at 05:23:11PM +0300, Reco wrote: > Hi. [...] > So I got bored and wrote the thing today. A customary disclaimer > follows: Wow. That was quick. Although I'm probably not going to use it: - hey, thanks a bunch! - I'm sure going to read it and play around with a bit Cheers - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlmyXOkACgkQBcgs9XrR2kZbcACdEJt50L0KBimk2ndn467lOk7t wj8An1c5s3MewdxrwJ1a4g9Atzk4SKFl =CAni -END PGP SIGNATURE-
Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 )
> First, this LD_PRELOAD library does exactly one thing - it downgrades > default TLS version to TLS1.0. If your users have the trouble connecting > to your mailserver because their clients cannot do TLS1.2 and that's the > only thing your mailserver advertizes - your users still won't be able > to connect after downgrading *their* end to TLS1.0. > Second, I somehow doubt that your users' MUAs are based on openssl. > Third, since then LD_PRELOAD works on Windows? First, using your LD_PRELOAD hack on the Debian server, if a client connects and DOES support TLSv1.2, will use 1.2 or 1.0? Second, reading the code, and I'm no expert with the openssl library, does this cause "outbound" connections to be version 1.0? If I understand you and your code properly, that's what it's going to do. I don't know if there's a mechanism in TLS to start with 1.2 and fail back to a lesser version if the other end doesn't support it. > What you *can* do with this library is to deploy it on your *server* and > LD_PRELOAD cirrus/dovecot/exim/postfix/whatever you have there. It may > even work (I haven't tried it though). Yes of course! I had no intention of trying to install this on the clients! I have not tried your hack yet either. > 'if you have to do a > server - you use Debian stable'. Why am I using Debian Testing? I have been using Testing for several years now and this is the first such issue I've had where it wasn't clear what to do. And as stated, this issue will probably find it's way into Stable too, this is just a preview. Several years ago I was running Stable but I found that there were many packages that did not make it into back-ports. I was constantly in situations where packages I needed to install simply were not available in stable and they had dependencies which I could not easily resolve. I did not want to start building my own packages. After frustration upon frustration, I finally moved to testing and all my problems like this disappeared. I have been delighted with the Testing branch. It's very very stable and in the odd case where it isn't, pinning a package for a while has not caused me problems. However, this situation is different as this package might need to be pinned for YEARS. And as we've said, it's probably going to affect Stable as well at some point and then I may be forced to do something different. What about publicly forking the libssl1 package (like Sven did privately) and having a version of this that tracks all the bug fixes and improvements except the 1.2 requirement? Once you install it, it over-rides/replaces the original. There is probably a right way to do this. Ok so I'm not running a university or a large business. I'm just doing this for a bunch of professional friends and family, still I treat it like real infra since we all have livelihoods that depend on this infra.
Re: Windows program on Debian
On 9/6/17, Gary Roach wrote: > On 09/05/2017 07:10 PM, 黃世緯 wrote: >> My computer is 11 years old, with single-channel ram, 80GB IDE hard >> drive etc. >> >> The most important thing is the virtualisation, is it okay to install >> Windows programme on linux? >> > I've been experimenting with KVM virtual machine lately. I've also used > wine and Virtual Box in the past. I found wine to be a pain. Virtual Box > is ok but KVM, on the other hand, installed with little trouble. After > that you can load any OS into KVM and have no conflict with the parent > OS. I think it is the best choice if you wish to run multiple OS's on > any system. Gary's observation inspired me to search apt-get for that. Something called "mom" popped up in a decent list of other packages: Description-en: Dynamically manage system resources on virtualization hosts MOM is a policy-driven tool that can be used to manage overcommitment on KVM hosts. Using libvirt, MOM keeps track of active virtual machines on a host. At a regular collection interval, data is gathered about the host and guests. Data can come from multiple sources (eg. the /proc interface, libvirt API calls, a client program connected to a guest, etc). Once collected, the data is organized for use by the policy evaluation engine. When started, MOM accepts a user-supplied overcommitment policy. This policy is regularly evaluated using the latest collected data. In response to certain conditions, the policy may trigger reconfiguration of the system’s overcommitment mechanisms. Currently MOM supports control of memory ballooning and KSM but the architecture is designed to accommodate new mechanisms such as cgroups. Just throwing it out there because of this thread being about very finite resources. At the very least, it shows there's some thought about this going on in our repositories. Maybe some keywords from it might land other packages of related interest Cindy :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * runs with duct tape *
Re: rsnapshot
On Thu, Sep 07, 2017 at 09:40:21PM +0200, Jochen Spieker wrote: > Pol Hallen: > > 00 01 * * * root/usr/bin/rsnapshot alpha > > 30 3 * * * root/usr/bin/rsnapshot beta > > alpha will be run daily at 01:00 am and beta daily at 03:30 am. Is this > what you want? Just be careful with local time zone daylight saving time changes. Once a year, in my time zone, those two times will occur 90 minutes apart, instead of 150 minutes apart. (And also once a year, they will occur 210 minutes apart.)
Re: Upgrade from jessie to strech wants to bloat by system
On 9/7/17, Ben Finney wrote: > Urs Thuermann writes: > >> I see that some new versions of packages are installed without the old >> versions being removed, although they are marked as automatically >> installed, e.g. Linux kernel, clang, llvm, and some others. For >> example >> >> # aptitude search "~i clang" >> i clang - C, C++ and Objective-C compiler (LLVM >> based) >> i A clang-3.5 - C, C++ and Objective-C compiler (LLVM >> based) >> i A libclang-common-3.5-dev - clang library - Common development >> package >> i A libclang1-3.5 - C interface to the clang library > > That shows the ‘clang’ package is *not* marked auto-installed. That is, > the APT database shows it was manually requested, and so will never be > auto-removed. Oh, oh, o.. Quite a while back I observed on here that apt-get tells me packages are now marked as manually installed if I (accidentally) do an "apt-get install" command on a package that turns out to already be current. That happened to me regularly when I was having to break my upgrades into small sized chunks while doing them every day (k/t small town dialup access). I'd *almost* be willing to bet that your "the APT database shows it was manually requested, and so will never be auto-removed" comes into play with respect to that apt-get advisement. It would be interesting to test it if that actually does... :) Cindy :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * runs with duct tape *
Re: rsnapshot
On Friday, September 08, 2017 08:24:09 AM Greg Wooledge wrote: > On Thu, Sep 07, 2017 at 09:40:21PM +0200, Jochen Spieker wrote: > > Pol Hallen: > > > 00 01 * * * root/usr/bin/rsnapshot alpha > > > 30 3 * * * root/usr/bin/rsnapshot beta > > > > alpha will be run daily at 01:00 am and beta daily at 03:30 am. Is this > > what you want? > > Just be careful with local time zone daylight saving time changes. > Once a year, in my time zone, those two times will occur 90 minutes > apart, instead of 150 minutes apart. (And also once a year, they > will occur 210 minutes apart.) That's one reason I like to use GMT instead of local time for things "within" the computer--then I can decide how I want to deal with things like time changes due to daylight savings time (or moving / traveling) between different time zones.
Actually, it was STUPID, not weird (cross-posted to Tomcat and Debian Lists): my BROWSER CACHES never got flushed!
I really can't believe I didn't think about the possibility that my browsers were both still caching the default root context from Tomcat 7 when I did the port swap. I definitely need to always remember to consider the possibility that I'm doing something stupid. -- JHHL
Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 )
Hi. On Fri, Sep 08, 2017 at 10:20:22AM +0100, Michael Grant wrote: > > First, this LD_PRELOAD library does exactly one thing - it downgrades > > default TLS version to TLS1.0. If your users have the trouble connecting > > to your mailserver because their clients cannot do TLS1.2 and that's the > > only thing your mailserver advertizes - your users still won't be able > > to connect after downgrading *their* end to TLS1.0. > > Second, I somehow doubt that your users' MUAs are based on openssl. > > Third, since then LD_PRELOAD works on Windows? > > First, using your LD_PRELOAD hack on the Debian server, if a client > connects and DOES support TLSv1.2, will use 1.2 or 1.0? Untested. Since I know next to nothing about MTAs - all that's required of me is to setup a smarthost and that's it - I can not setup a meaningful test environment. I could try to poke a dovecot though, but it will take time. My best understanding of this is if a TLS server does not specify an exact version of protocol used then "old" openssl just assumes that TLS1.0, TLS1.1 and TLS1.2 should be used at once. "New" openssl just provides TLS1.2 *unless* you find a way to specify exact version of TLS that's to be used (nginx can be told to do so for instance). LD_PRELOAD hack (please stop calling it mine - I've forsaken authorship of it) forces it to be TLS1.0 *only*. Unless you change the code, of course. > Second, reading the code, and I'm no expert with the openssl library, > does this cause "outbound" connections to be version 1.0? That was the original idea. The code was written to scratch a particular itch, and it was to force plain openssl and ncat (from nmap) to use TLS1.0. > If I > understand you and your code properly, that's what it's going to do. > I don't know if there's a mechanism in TLS to start with 1.2 and fail > back to a lesser version if the other end doesn't support it. That's where an openssl expert is needed. I won't claim to be the one. > > 'if you have to do a > > server - you use Debian stable'. > > Why am I using Debian Testing? I have been using Testing for several > years now and this is the first such issue I've had where it wasn't > clear what to do. And as stated, this issue will probably find it's > way into Stable too, this is just a preview. True. But by that time the dust should settle and the suitable workaround would be found. The difference between "stable" and "testing" is that the users of the latter need it now. The users of the former can afford to wait and see how it plays out. > Several years ago I was running Stable but I found that there were > many packages that did not make it into back-ports. I was constantly > in situations where packages I needed to install simply were not > available in stable and they had dependencies which I could not easily > resolve. I did not want to start building my own packages. After > frustration upon frustration, I finally moved to testing and all my > problems like this disappeared. I have been delighted with the > Testing branch. Interesting. Care to share which packages did you lack for *server* purposes? > What about publicly forking the libssl1 package (like Sven did > privately) and having a version of this that tracks all the bug fixes > and improvements except the 1.2 requirement? Once you install it, it > over-rides/replaces the original. There is probably a right way to do > this. I don't know since I'm way too lazy to fork an openssl singlehandedly. I trust Debian project as I've installed their OS numerous times. Why should I trust some guy or gal (whom I don't acquainted with, no offence meant) to provide me with such security-sensitive package? Reco
Re: Debian Stretch doesn't boot without Monitor
I was not able to solve the problem properly, so I made a workaround by using a EDID VGA-Adapter(Lindy EDID/DDC Adapter for VGA-Displays) . On 2017-08-21 11:02, Wolfgang wrote: > Hi, > > I have an embedded device(/small pc) and I want to run Debian Stretch on > it. But I am experiencing a strange problem: it doesn't boot without > monitor. I created the following cronjob to verify if its > up'n'running(or not): > > @reboot root beep -f 300.7 -r 2 -d 100 -l 400 > > My first guess was: some weird BIOS-Setting. But I didn't find any weird > BIOS-setting. So I tried to run a different OS, and it booted up correctly. > > I also tried to use the Debian-Stretch-Disk on another hardware and it > boots even without a monitor. The problem seems to be a related with my > hardware. > > The device has intel-graphics: i915 > > I installed(without success) the following firmware/microcode: > firmware-amd-graphics > firmware-linux > firmware-linux-free > firmware-linux-nonfree > firmware-misc-nonfree > amd64-microcode > intel-microcode > > Does anyone have a clue? > > Thanks in advance > Wolfgang >
Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 )
On Fri 08 Sep 2017 at 09:33:59 +0200, Sven Hartge wrote: > Michael Grant wrote: > > > If this patch won't go to Stretch as a security fix, then the world is > > hidden from this until Buster comes out in about 2 years. > > Exactly. Read the discussion(s) in debian-devel about this. The last > idea was to have Buster semi-broken until shortly before the release and > then switch back on TLS1.0 and TLS1.1 support. I didn't quite read it like this. The -devel discussions had a broad consensus regarding the change in buster but the maintainer has laid his stall out. > My problem is that if we don't do something, TLS 1.0 will be used > for an other 10 year, and that's just not acceptable. So I would > like to do something so that hopefully by the time Buster releases > you can disable TLS 1.0 by default, and that almost no users would > need to enable it again. > > Disabling the protocols is the only way I know how to identify > all the problems. And I would like to encourage everybody to > contact the other side if things break and get them to upgrade. There you are. Everyone who is affected by this change can use their persuasive powers to bring about change. Microsoft, Google etc will be overwhelmed by the Debian shock troops and fall into line. And again: > I have a patch for that at: > https://github.com/openssl/openssl/pull/4128 > > I might upload this soon. The intention is still to ship Buster > with TLS 1.0 and 1.1 completly disabled. Couldn't be clearer. The maintainer does not plan to switch back to TLS1.0 and TLS1.1 support, even as a configurable option. Fancy being cannon fodder? ;) -- Brian.
Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 )
Brian wrote: > And again: >> I have a patch for that at: >> https://github.com/openssl/openssl/pull/4128 >> >> I might upload this soon. The intention is still to ship Buster >> with TLS 1.0 and 1.1 completly disabled. > Couldn't be clearer. The maintainer does not plan to switch back to > TLS1.0 and TLS1.1 support, even as a configurable option. Fancy being > cannon fodder? ;) I see a decisision from the CTTE on that matter in the future. S° -- Sigmentation fault. Core dumped.
Re: unable to determine which package my bug report should be filed against - please advise.
On Thu, 07 Sep 2017, DM wrote: > I am not sure exactly what may be the cause of the issue, and I am > reaching out to you for help to identify what part of Debain might be > causing this issue. This sounds like your monitor might not be returning the correct EDID or Debian isn't handling it appropriately. > The issue: I am using a second monitor (external monitor connected via > a displayport - LG 29UM57-P). External monitor connected to my laptop > - Lenovo T420. External monitor does not display video at the desired > resolution and the aspect ratio. > > Displayed resolution - 1920 x 1080 > Displayed aspect ratio - 16:9 > > Expected resolution - 2560 x 1080 > Expected ratio - 21:9 > > This same exact issue exist on my other machine Lenovo X230 with > external monitor of exact same model. These machines all use the intel graphics driver, so you should file this bug against the xserver-xorg-video-intel package. [You can verify that by checking /var/log/Xorg.0.log and seeing if you see lots of "intel(0)" lines there.] > Previous version of Debian 8 (jessie) worked with out any issue with > the monitor at the correct and expected resolution and the aspect > ratio. > > After installing a fresh version of Debian 9 (Stretch), I am unable to > use the external monitor at its maximum resolution. Debian 9 (Stretch) > was a full installation from scratch (not an upgrade). When you file the bug, please also include the output of xrandr --verbose; -- Don Armstrong https://www.donarmstrong.com They say when you embark on a journey of revenge dig two graves. They underestimate me. -- a softer world #560 http://www.asofterworld.com/index.php?id=560
Re: Recommended editor for novice programmers?
On Fri 08 Sep 2017 at 03:24:11 (+0100), Nick Boyce wrote: > On Wed, 06 Sep 2017 16:19:03 +1000 > Ben Finney wrote: > > > Nick Boyce writes: > > > > > I don't want to provoke any religious war here, and sorry if I offend > > > anybody, but: > > > > That doesn't alter the fact that you've disparaged programs in terms > > that state an absolute problem inherent to the program. This is not > > helpful, because it implies that people who choose those programs are > > wrong and should be disparaged themselves. > > I do disparage software when it seems ungood, but there is no implication > from me that people who use that software are in any way to be disparaged - > there may be many reasons why they're using that software, and my (possibly > mistaken) opinion may even help them realise they have choices they didn't > know about. We all have to start learning somewhere - and it never ends. > > > > > For example: > > > > > emacs is ridiculously heavy-weight > > > > That's an absolute statement of objective fact. > > I realise I should have scattered IM(H)Os all through my email, so lets start > now: IMO it *is* an objective fact. emacs is *huge* (please don't ask me for > numbers) and cumbersome and overengineered if what you want is a lightweight > lean fast straightforward text editor (and I usually do). No, the ridiculous thing here is the contradiction: "IMO it *is* an objective fact", and it's immediately followed by a circular argument. Now, it's arguable that emacs is large compared with many other editors. However, it contains a lot of functionality, and that means lots of code. But just how important is the volume of code that's available when you're actually editing a file? I'm typing on a i386 laptop with 500MB of memory. Editing a 25MB file, the memory reported by top is emacs 15% nano 7.5% Meanwhile, I have firefox open on the results of a google search. That's currently reading firefox-esr 31% + Web Content 28% By way of contrast, if I boot up the machine, start X (using the fvwm window manager) and bring up the wunderground weather forecast on opera (far faster than using firefox), the machine uses all 500MB of memory and 300MB of the 1GB swap. As you can imagine, it's not quick. So, with respect to this laptop, the size of emacs is irrelevant. > I remember an operating system whose response to commands was only ever 'OK' > or 'ER' I don't like to tell you what I thought about that, but some > people liked it because it didn't waste their time with verbiage. OK would be rather verbose for Unix. Cheers, David.
Re: Editor survival [Was: Recommended editor for novice programmers?]
On Fri 08 Sep 2017 at 03:19:49 (+0100), Nick Boyce wrote: > You're absolutely right. I have sat next to seasoned vi users watching in > awe as their fingers flew entering weird totally non-intuitive commands (to > me) and achieving great edits in next to no time. Other colleagues lived > inside emacs all day long, using it as a sort of OS with an editor attached. > I used other editors to achieve the same goals, quite possibly taking more > real time than the vi guys. Each to their own. > Agreed .. or whatever terminal (emulation) you're actually using - in my case > very often a real VT220/320/420, attached to a VMS, then TELNETed to a Un*x, > where the available /etc/termcap|terminfo may or may not have been well > crafted back at the factory. Sometimes an ICL mainframe VDU connected via an > obscure 3rd-party emulation converter box to a DEC machine. Latterly it > would be some 3rd-party terminal emulator on Windows 3.1/95. I still say ugh, > though it may well not be vi's fault. The fact is that miraculously 'joe' > seemed to be much more resilient and usable in these circumstances. As did > emacs .. if you could afford to wait. I like an editor to appear within 1 > second of me calling it (which rules out most GUI editors). Just to point out there's a connection between these two paragraphs. You shouldn't have to wait even a second for emacs to start if you "live" in it, ie use the server-start command and keep a running instance open. Then, instead of emacs, invoking emacsclient from the shell and applications will be virtually instant. Cheers, David.
top that shows "Web Content" (was Re: Recommended editor for novice programmers?)
On Friday, September 08, 2017 05:13:31 PM David Wright wrote: > Meanwhile, I have firefox open on the results of a google search. > That's currently reading > firefox-esr 31% + Web Content 28% Hmm, do you have a version of top (or something else) which reports the use of memory for web content? I don't see that in top on Wheezy., but I'd like to get that number.
Re: OT: Re: Suitable text ed
On Thu 07 Sep 2017 at 20:25:23 (-0400), Gene Heskett wrote: > On Thursday 07 September 2017 15:38:24 Joe wrote: > > On Thu, 7 Sep 2017 14:40:22 -0400 Gene Heskett wrote: > > > Neither did I, but then it seems to be a coin toss as to whether mc > > > calls nano, or uses its own editor. Something controls it, but I > > > haven't sussed what. > > > > Options -> Configuration.. use internal edit X. > > Thanks. Turned out the diff was as me, or as root Fair enough. That probably wouldn't cross my mind as there are programs I never use as root; amongst them, mc, emacs, browsers, and X itself of course. Cheers, David.
Workable installation of VTK and GWT
I have been trying for weeks to install the Elmer FEM program from the Git repository. I have constantly had the problem that the program will require the installation of some program or library that Debian doesn't specifically list. If I search by program name I get a long list of library functions with permutations containing the name for which I did the search. I am down to VTK and GWT installations. Can any one tell me what constitutes a working installation of these packages. The Elmer program is written in a combination of C, C++ and Fortran. Debian Stretch KED Desktop Athlon FX processor Installation on KVM virtual machine. Gary R
Re: Re: LibreOffice - middle click paste does not work.
Same issue here! Middle button doesn't paste from Firefox webpage to Vim, nor to libreoffice Writer. How to reproduce: 1. open firefox and Writer 2. access www.google.com 3. select some word 4. focus on Writer 5. click middle button in a document FAILL -- Marcelo
Re: top that shows "Web Content" (was Re: Recommended editor for novice programmers?)
On Fri 08 Sep 2017 at 17:39:39 (-0400), rhkra...@gmail.com wrote: > On Friday, September 08, 2017 05:13:31 PM David Wright wrote: > > Meanwhile, I have firefox open on the results of a google search. > > That's currently reading > > firefox-esr 31% + Web Content 28% > > Hmm, do you have a version of top (or something else) which reports the use > of > memory for web content? I don't see that in top on Wheezy., but I'd like to > get that number. I don't have any browsers on my wheezy systems, but is it possible that wheezy calls it plugin-container? That is what ps calls it in jessie, but I used top's value and terminology. Another name to check out might be xul-runner which is where plugin-container used to live. Cheers, David.
Re: Recommended editor for novice programmers?
I'm dropping in late to say that running 'vimtutor' in a terminal is an easy way to interactively get to know how vim works. -- Joel Roth
ot : seahorse
ot : seahorse _ https://askubuntu.com/questions/851875/cannot-add-keyservers-in-seahorse Ilia Draga use dconf-editor: /desktop/gnome/crypto/pgp/keyservers > custom value (see Default) and add : hkps://hkps.pool.sks-keyservers.net as first server (['hkps:', '*', '*',]) _ https://sks-keyservers.net/overview-of-pools.php optional : # Don't leak DNS. #keyserver-options no-try-dns-srv This option no longer exists, you can disable SRV lookups by explicitly specifying a port number when setting the keyserver, as in: keyserver hkps.pool.sks-keyservers.net:443
Re: Re: LibreOffice - middle click paste does not work.
On 9/8/17, Marcelo Laia wrote: > Same issue here! > > Middle button doesn't paste from Firefox webpage to Vim, nor to libreoffice > Writer. > > How to reproduce: > > 1. open firefox and Writer > 2. access www.google.com > 3. select some word > 4. focus on Writer > 5. click middle button in a document FAILL It worked for me, and that's with a messed up middle button. Buster Testing with Linux kernel 4.12.8 Xfce4 desktop environment Firefox 52.2.0 Libreoffice Writer Version: 5.2.7.2/Build ID: 1:5.2.7-1 (on developer controlled hold for ages) Vim 2:8.0.0197-5+b1 (via apt-get showpkg) Cindy :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * runs with duct tape *
Re: LibreOffice - middle click paste does not work.
On 2017-09-08 at 22:47, Cindy-Sue Causey wrote: > On 9/8/17, Marcelo Laia wrote: > >> Same issue here! >> >> Middle button doesn't paste from Firefox webpage to Vim, nor to libreoffice >> Writer. >> >> How to reproduce: >> >> 1. open firefox and Writer >> 2. access www.google.com >> 3. select some word >> 4. focus on Writer >> 5. click middle button in a document FAILL > > > It worked for me, and that's with a messed up middle button. > > Buster Testing with Linux kernel 4.12.8 > Xfce4 desktop environment > Firefox 52.2.0 > Libreoffice Writer Version: 5.2.7.2/Build ID: 1:5.2.7-1 (on developer > controlled hold for ages) > Vim 2:8.0.0197-5+b1 (via apt-get showpkg) It seems to have broken in 5.4.0, and apparently has been fixed in 5.4.1 (now available in testing), judging from reading bug #871588 (which appears to have been filed as follow-on to this thread). -- 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
