You are here

Agreguesi i feed

What is the New York Cybersecurity Regulation? What you need to do to comply

LinuxSecurity.com - Enj, 07/06/2018 - 10:43pd
LinuxSecurity.com: In March 2017, the New York State Department of Financial Services (DFS) implemented 23 NYCRR 500, generally referred to as the New York Cybersecurity Regulation. Its aim is to encourage financial services firms doing business in the state to minimize their security risks. Although many experts see the regulation as flawed, 23 NYCRR 500 is expected to set a precedent for cybersecurity laws and regulations in other states.

#Infosec18: Nation State Hacking is Biggest Change in Cyber-Threat Landscape

LinuxSecurity.com - Enj, 07/06/2018 - 10:38pd
LinuxSecurity.com: The former director general of GCHQ Robert Hannigan took to the keynote stage at Infosecurity Europe 2018 to discuss the evolving cyber-threat landscape, describing how - whilst changes in sophistication of lone actors and cyber-criminals are increasing the challenges of keeping data secure - it is the rise of nation state attacks that is "possibly the biggest change in the last couple of years."

MyHeritage Alerts Users to Data Breach

LinuxSecurity.com - Mër, 06/06/2018 - 12:11md
LinuxSecurity.com: MyHeritage, a platform designed to investigate family history, learned of a data breach on June 4, 2018. It reports the incident affected email addresses and hashed passwords of nearly 92.3 million users who signed up for the site before and including Oct. 26, 2017, the date of the incident.

Open-source security: Zip Slip critical flaw hits thousands of projects. Update now

LinuxSecurity.com - Mër, 06/06/2018 - 12:09md
LinuxSecurity.com: Security firm Snyk has disclosed a widespread and critical flaw in multiple archive file-extraction libraries found in thousands of open-source web application projects from HP, Amazon, Apache, Oracle, LinkedIn, Twitter and others.

next-20180605: linux-next

Kernel Linux - Mar, 05/06/2018 - 1:40md
Version:next-20180605 (linux-next) Released:2018-06-05

4.16.14: stable

Kernel Linux - Mar, 05/06/2018 - 11:46pd
Version:4.16.14 (stable) Released:2018-06-05 Source:linux-4.16.14.tar.xz PGP Signature:linux-4.16.14.tar.sign Patch:full (incremental) ChangeLog:ChangeLog-4.16.14

4.14.48: longterm

Kernel Linux - Mar, 05/06/2018 - 11:42pd
Version:4.14.48 (longterm) Released:2018-06-05 Source:linux-4.14.48.tar.xz PGP Signature:linux-4.14.48.tar.sign Patch:full (incremental) ChangeLog:ChangeLog-4.14.48

#Infosec18: Regulation is Top Driver of Cybersecurity, Now & in the Future

LinuxSecurity.com - Mar, 05/06/2018 - 11:06pd
LinuxSecurity.com: Infosecurity has released the findings of a recent survey of senior industry professionals to determine the key trends that are currently driving cybersecurity spending and behaviors, and what factors will drive it in the next five years.

Phishing Scams Target FIFA World Cup Attendees

LinuxSecurity.com - Mar, 05/06/2018 - 11:00pd
LinuxSecurity.com: Major sporting events attract fans and cybercriminals alike. Earlier this year, attackers targeted the 2018 Winter Olympics in Pyeongchang; now their sights are on the 2018 FIFA World Cup. Soccer-related spam is ramping up ahead of the event, which begins in less than two weeks.

4.9.106: longterm

Kernel Linux - Mar, 05/06/2018 - 10:29pd
Version:4.9.106 (longterm) Released:2018-06-05 Source:linux-4.9.106.tar.xz PGP Signature:linux-4.9.106.tar.sign Patch:full (incremental) ChangeLog:ChangeLog-4.9.106

North Korean hacking group Covellite abandons US targets

LinuxSecurity.com - Hën, 04/06/2018 - 2:40md
LinuxSecurity.com: Cyberattackers linked to North Korea have appeared to have withdrawn from attacks on the US industrial sector.

Security fail? One in three companies think paying hackers is worth the risk

LinuxSecurity.com - Hën, 04/06/2018 - 2:37md
LinuxSecurity.com: A third of organisations would consider paying a ransom to hackers instead of investing more in security a survey has claimed.

4.17: mainline

Kernel Linux - Dje, 03/06/2018 - 11:15md
Version:4.17 (mainline) Released:2018-06-03 Source:linux-4.17.tar.xz PGP Signature:linux-4.17.tar.sign Patch:full

Customer Data Flies Away with Ticketfly Hacker

LinuxSecurity.com - Dje, 03/06/2018 - 11:02pd
LinuxSecurity.com: Ticket distribution service Ticketfly was hacked by a culprit who took responsibility for defacing the company's homepage with a message citing poor security as the reason for not apologizing.

5 Tips for Protecting SOHO Routers Against the VPNFilter Malware

LinuxSecurity.com - Dje, 03/06/2018 - 10:32pd
LinuxSecurity.com: News of how the Russians are alleged to have infected more than 500,000 home routers worldwide via the VPNFilter malware broke last week, leaving home users and security managers scratching their heads about how to best to lock themselves down.

Cybercrime Is Skyrocketing as the World Goes Digital

LinuxSecurity.com - Sht, 02/06/2018 - 10:46pd
LinuxSecurity.com: If cybercrime were a country, it would have the 13th highest GDP in the world.

Fitness app PumpUp left users' personal data exposed on server

LinuxSecurity.com - Sht, 02/06/2018 - 10:39pd
LinuxSecurity.com: While it's not at the catastrophic level of MyFitnessPal's 150 million-user data breach , the company behind the workout app PumpUp left information for 6 million of its members exposed. The Amazon cloud-hosted back-end server holding the data didn't have a password set up for an uncertain lenght of time, enabling anyone to observe sign-ins and exchanged messages.

3.2.102: longterm

Kernel Linux - Pre, 01/06/2018 - 1:30pd
Version:3.2.102 (longterm) Released:2018-05-31 Source:linux-3.2.102.tar.xz PGP Signature:linux-3.2.102.tar.sign Patch:full (incremental) ChangeLog:ChangeLog-3.2.102

Michael Catanzaro: Thoughts on Flatpak after four months of Epiphany Technology Preview

Planet GNOME - Hën, 28/05/2018 - 1:52pd

It’s been four months since I announced Epiphany Technology Preview — which I’ve been using as my main browser ever since — and five months since I announced the availability of a stable channel via Flatpak. For the most part, it’s been a good experience. Having the latest upstream development code for everything is wonderful and makes testing very easy. Any user can painlessly download and install either the latest stable version or the bleeding-edge development version on any Linux system, regardless of host dependencies, either via a couple clicks in GNOME Software or one command in the terminal. GNOME Software keeps it updated, so I always have a recent version. Thanks to this, I’m often noticing problems shortly after they’re introduced, rather than six months later, as was so often the case for me in the past. Plus, other developers can no longer complain that there’s a problem with my local environment when I report a bug they can’t reproduce, because Epiphany Technology Preview is a canonical distribution environment, a ground truth of sorts.

There have been some rough patches where Epiphany Technology Preview was not working properly — sometimes for several days — due to various breaking changes, and the long time required to get a successful SDK build when it’s failing. For example, multimedia playback was broken for all of last week, due to changes in how the runtime is built. H.264 video is still broken, since the relevant Flatpak extension is only compatible with the 3.28 runtime, not with master. Opening files was broken for a while due to what turned out to be a bug in mutter that was causing the OpenURI portal to crash. I just today found another bug where closing a portal while visiting Slack triggered a gnome-shell crash. For the most part, these sorts of problems are expected by testers of unstable nightly software, though I’m concerned about the portal bugs because these affect stable users too. Anyway, these are just bugs, and all software has bugs: they get fixed, nothing special.

So my impression of Flatpak is still largely positive. Flatpak does not magically make our software work properly in all host environments, but it hugely reduces the number of things that can go wrong on the host system. In recent years, I’ve seen users badly break Epiphany in various ways, e.g. by installing custom mimeinfo or replacing the network backend. With Flatpak, either of these would require an incredible amount of dedicated effort. Without a doubt, Flatpak distribution is more robust to user error. Another advantage is that we get the latest versions of OS dependencies, like GStreamer, libsoup, and glib-networking, so we can avoid the many bugs in these components that have been fixed in the years since our users’ LTS distros froze the package versions. I appreciate the desire of LTS distros to provide stability for users, but at the same time, I’m not impressed when users report issues with the browser that we fixed two years ago in one dependency or another. Flatpak is an excellent compromise solution to this problem: the LTS distro retains an LTS core, but specific applications can use newer dependencies from the Flatpak runtime.

But there is one huge downside to using Flatpak: we lose crash reports. It’s at best very difficult — and often totally impossible — to investigate crashes when using Flatpak, and that’s frankly more important than any of the gains I mention above. For example, today Epiphany Technology Preview is crashing pretty much constantly. It’s surely a bug in WebKit, but that’s all I can figure out. The way to get a backtrace from a crashing app in flatpak is to use coredumpctl to manually dump the core dump to disk, then launch a bash shell in the flatpak environment and manually load it up in gdb. The process is manual, old-fashioned, primitive, and too frustrating for me by a lot, so I wrote a little pyexpect script to automate this process for Epiphany, thinking I could eventually generalize it into a tool that would be useful for other developers. It’s a horrible hack, but it worked pretty well the day I tested it. I haven’t seen it work since. Debuginfo seems to be constantly broken, so I only see a bunch of ???s in my backtraces, and how are we supposed to figure out how to debug that? So I have no way to debug or fix the WebKit bug, because I can’t get a backtrace. The broken, inconsistent, or otherwise-unreliable debuginfo is probably just some bug that will be fixed eventually (and which I half suspect may be related to our recent freedesktop SDK upgrade. Update: Alex has debugged the debuginfo problem and it looks like that’s on track to be solved), but even once it is, we’re back to square one: it’s still too much effort to get the backtrace, relative to developing on the host system, and that’s a hard problem to solve. It requires tools that do not exist, and for which we have no plans to create, or even any idea of how to create them.

This isn’t working. I need to be able to effortlessly get a backtrace out of my application, with no or little more effort than running coredumpctl gdb as I would without Flatpak in the way. Every time I see Epiphany or WebKit crash, knowing I can do nothing to debug or investigate, I’m very sorely tempted to switch back to using Fedora’s Epiphany, or good old JHBuild. (I can’t promote BuildStream here, because BuildStream has the same problem.)

So the developer experience is just not good, but set that aside: the main benefits of Flatpak are for users, not developers, after all. Now, what if users run into a crash, how can they report the bug? Crash reports are next to useless without a backtrace, and wise developers refuse to look at crash reports until a quality backtrace has been posted. So first we need to fix the developer experience to work properly, but even then, it’s not enough: we need an automatic crash reporter, along the lines of ABRT or apport, to make reporting crashes realistically-achievable for users, as it already is for distro-packaged apps. But this is a much harder problem to solve. Such a tool will require integration with coredumpctl, and I have not the faintest clue how we could go about making coredumpctl support container environments. Yet without this, we’re asking application developers to give up their most valuable data — crash reports — in order to use Flatpak.

Eventually, if we don’t solve crash reporting, Epiphany’s experiment with Flatpak will have to come to an end, because that’s more important to me than the (admittedly-tremendous) benefits of Flatpak. I’m still hopeful that the ingenuity of the Flatpak community will find some solutions. We’ll see how this goes.

Jim Hall: Librem 13: A few problems

Planet GNOME - Dje, 27/05/2018 - 11:45md
I bought my old Lenovo Thinkpad X1 Carbon (1st gen.) when I entered grad school for my Master's program, in 2012. And after six years, the Thinkpad still ran well, but it was getting old, so I figured it was time for a change. I went back and forth about what kind of system should replace my laptop. I don't travel that much, so I figured a desktop would be better. And I could get a bigger screen.

After going back and forth on the decision, I decided to get a laptop. I don't often travel with a laptop, but when I do, I prefer to use my primary system so I don't have to keep things synced. Of course, I wanted my system to run Linux. Purism is aimed at the Linux laptop market, and I wanted to support that. So I bought a Librem 13.

I've had it now for about a week, and I love it now. But I'll be honest, I didn't love it right out of the box. I'd like to note two issues for folks who are thinking about getting a Librem laptop, so you aren't surprised like I was.

1. The backslash key sends the wrong key codeThe Purism laptop uses a keyboard that sends the wrong key code for the backslash key (\). The "shift" on this key is the pipe symbol (|). So you know, you need these. Try running any commands at the Linux command line, and you'll quickly run into a problem where you can't send the output of one program into another program. You need the pipe for that. Or try escaping a character at the command line, or in program code. You need the backslash for that.

This is a known issue on the Librem. Every other keyboard known to man gets this right, but I guess Purism used a different keyboard.

To fix, you need to set setkeycodes 56 43 to reset the correct key codes for that key system-wide. To make the fix permanent, create a new /etc/rc.d/rc.local file that is mode 750 and has these lines:

#!/bin/bash
setkeycodes 56 43
exit 0

Here's the file entry:

-rwxr-x---. 1 root root 37 May 22 18:50 /etc/rc.d/rc.local

This fixes the problem each time the system boots. You don't need to do anything at the user level. Note that I have my Librem connected to an external display, and I'm using an external keyboard and mouse. This key code fix doesn't impact backslash or pipe on my external keyboard, so I'm good there.2. The Intel video card gives serious video flickerWhen I first booted the Librem, it was using the pre-installed PureOS Linux distribution. I played with it for a while, then decided I'd rather run the Fedora Linux distribution that I'm used to. But after I'd re-installed, I quickly realized I had a problem. The laptop screen would flicker at random times.

Ah well, I figured. This is a driver issue, just do an update. Except that every time I ran an update, the laptop display went to sleep. Very annoying. In the end, I had to boot into run level 3, and run the update from text mode. The screen still flickered once in a while, but not as badly, and the display didn't go to sleep.

It turns out that this is also a known issue. Some users reported that using i915.enable_rc6=0 as a kernel option will prevent or reduce the issue. Or you can try i915.enable_psr=0. But on my Librem, neither seemed to completely fix the problem. I still get flicker on the laptop display. I'm not sure what kernel settings Purism used in the pre-installed PureOS Linux, since I wiped that when I re-installed with Fedora Linux.

The problem is likely caused in the Intel i915 power management driver. Also reported as Constant display flicker after i915 is initialised. For the Librem suggested fix, see Troubleshooting > Screen Flickering.

Interestingly, I don't get this problem when I'm using only the external display. I mentioned that I have my Librem connected to an external display, and I'm using an external keyboard and mouse. I set GNOME to only use the external display. I can still see the laptop's screen flicker at the graphical login screen (on the laptop display), but once GNOME switches to the external display, the laptop's display turns off so the problem doesn't seem to get triggered.With those two fixes in place (rc.local, and using an external display) I'm very happy with my Librem 13. I'm effectively using it as a desktop computer. I'm hoping there's a fix for the i915 video by the time I take my next trip in October, or I'll be very unhappy.

If you know of a better solution for the i915 display flicker problem, please let me know in the comments.

Update (6/6/18): I'm still having the screen flicker problem. I reached out to Purism via Twitter, and they asked that I open a support case, which I have. They've seen this on some machines.

Update (6/9/18): I shipped back my Librem 13 today. I feel better knowing this is a hardware issue that others have seen, and that it's fixable.

Faqet

Subscribe to AlbLinux agreguesi