(ℹ) Join us now at the IRC channel | ䷉ Find the plain text version at this address (HTTP) or in Gemini (how to use Gemini) with a full GemText version.
| *u-amarsh04 (~amarsh04@t25x9hgy9xhrc.irc) has joined #techbytes | Dec 17 02:01 | |
| *leah has quit (Ping timeout: 2m30s) | Dec 17 02:28 | |
| *leah (~leah@wrh2nipuzrd3y.irc) has joined #techbytes | Dec 17 03:32 | |
| *DaemonFC has quit (Ping timeout: 2m30s) | Dec 17 04:41 | |
| *DaemonFC (~daemonfc@f33xpkevtd8r6.irc) has joined #techbytes | Dec 17 04:47 | |
| *DaemonFC has quit (Ping timeout: 2m30s) | Dec 17 05:08 | |
| *DaemonFC (~daemonfc@g7jaun9d74heg.irc) has joined #techbytes | Dec 17 05:10 | |
| *DaemonFC has quit (Ping timeout: 2m30s) | Dec 17 05:24 | |
| *DaemonFC (~daemonfc@bcq5yw7bn3dta.irc) has joined #techbytes | Dec 17 05:25 | |
| *DaemonFC has quit (Ping timeout: 2m30s) | Dec 17 05:44 | |
| *leah has quit (Ping timeout: 2m30s) | Dec 17 05:49 | |
| *leah (~leah@wrh2nipuzrd3y.irc) has joined #techbytes | Dec 17 05:49 | |
| *leah has quit (connection closed) | Dec 17 05:52 | |
| *leah (~leah@wrh2nipuzrd3y.irc) has joined #techbytes | Dec 17 05:52 | |
| *DaemonFC (~daemonfc@gepqq28gg5c58.irc) has joined #techbytes | Dec 17 06:00 | |
| *u-amarsh04 has quit (Quit: Konversation terminated!) | Dec 17 06:07 | |
| *DaemonFC has quit (Quit: Leaving) | Dec 17 06:33 | |
| *leah has quit (connection closed) | Dec 17 07:14 | |
| *leah (~leah@wrh2nipuzrd3y.irc) has joined #techbytes | Dec 17 07:14 | |
| *u-amarsh04 (~amarsh04@t25x9hgy9xhrc.irc) has joined #techbytes | Dec 17 07:16 | |
| *u-amarsh04 has quit (Quit: Konversation terminated!) | Dec 17 08:13 | |
| schestowitz | https://www.fsf.org/about/board-of-directors-code-of-ethics | Dec 17 08:19 |
|---|---|---|
| -TechBytesBot/#techbytes-www.fsf.org | Board of Directors Code of Ethics — Free Software Foundation — Working together for free software | Dec 17 08:19 | |
| schestowitz | # caveat: the more rules there are the more they can be gamed | Dec 17 08:19 |
| schestowitz | x https://www.newscientist.com/article/2301706-what-is-web3-and-how-will-it-change-the-way-we-use-the-internet/ | Dec 17 08:22 |
| -TechBytesBot/#techbytes-www.newscientist.com | Web3: What is it and how will it change the way we use the internet? | New Scientist | Dec 17 08:22 | |
| schestowitz | x https://www.voanews.com/a/house-responds-to-gop-s-boebert-with-islamophobia-bill/6357589.html | Dec 17 08:22 |
| -TechBytesBot/#techbytes-www.voanews.com | US House Responds to Republican Boebert With Islamophobia Bill | Dec 17 08:22 | |
| *u-amarsh04 (~amarsh04@t25x9hgy9xhrc.irc) has joined #techbytes | Dec 17 08:33 | |
| *u-amarsh04 has quit (Quit: Konversation terminated!) | Dec 17 10:12 | |
| *u-amarsh04 (~amarsh04@t25x9hgy9xhrc.irc) has joined #techbytes | Dec 17 10:13 | |
| *u-amarsh04 has quit (Quit: Konversation terminated!) | Dec 17 11:57 | |
| *psydroid4 (~psydroid@cqggrmwgu7gji.irc) has joined #techbytes | Dec 17 12:18 | |
| *psydroid4 has quit (Quit: Leaving) | Dec 17 12:29 | |
| *psydroid4 (~psydroid@cqggrmwgu7gji.irc) has joined #techbytes | Dec 17 12:29 | |
| *tech_exorcist (~tech_exorcist@r8dui6smnhchc.irc) has joined #techbytes | Dec 17 12:39 | |
| schestowitz | Fwd: FinTech patents in China | Dec 17 12:44 |
| schestowitz | Bastian Best | Dec 17 12:44 |
| schestowitz | Bastian Best | Dec 17 12:44 |
| schestowitz | @https://twitter.com/bastianbest | Dec 17 12:44 |
| -TechBytesBot/#techbytes- ( status 400 @ https://mobile.twitter.com/bastianbest ) | Dec 17 12:44 | |
| schestowitz | Talking of DeFi and Fintech in general, I found an interesting article in The Patent Lawyer. Hui Li writes about Keeping up with Fintech: patent filing strategy. | Dec 17 12:44 |
| schestowitz | An interesting statement with respect to China: | Dec 17 12:44 |
| schestowitz | In particular, the revised patent examination guideline in 2019 and its proposed revision in 2021 substantially relieve the threshold for patent eligibility. Business method-related inventions, including Fintech, have a much better chance to be patentable, even without a substantial advancement in the traditional technical aspect. | Dec 17 12:44 |
| schestowitz | Link to the whole PDF magazine: https://patentlawyermagazine.com/wp-content/uploads/2021/12/TPL_Issue-57_interactive.pdf | Dec 17 12:44 |
| schestowitz | > Just got the attached e-mail telling me that the USPTO was shut down | Dec 17 12:49 |
| schestowitz | > because of fear of a cyber attack. | Dec 17 12:49 |
| schestowitz | Just add an update here (bottom part): | Dec 17 12:49 |
| schestowitz | http://techrights.org/2021/12/16/latest-epo-damage-control/ | Dec 17 12:49 |
| -TechBytesBot/#techbytes-techrights.org | The EPO is in ‘Damage Control’ Mode (and It Shows) | Techrights | Dec 17 12:49 | |
| *DaemonFC (~daemonfc@bcq5yw7bn3dta.irc) has joined #techbytes | Dec 17 17:33 | |
| schestowitz | redhat has just bumped these up | Dec 17 18:39 |
| schestowitz | <li><h5><a href="https://access.redhat.com/blogs/766093/posts/2262281">Red Hat Product Security Risk Report: 2015 - Red Hat Customer Portal</a></h5> | Dec 17 18:39 |
| -TechBytesBot/#techbytes- ( status 404 @ https://access.redhat.com/blogs/766093/posts/2262281">Red ) | Dec 17 18:39 | |
| schestowitz | <blockquote><p>This report takes a look at the state of security risk for Red Hat products for calendar year 2015. We look at key metrics, specific vulnerabilities, and the most common ways users of Red Hat products were affected by security issues. | Dec 17 18:39 |
| schestowitz | Our methodology is to look at how many vulnerabilities we addressed and their severity, then look at which issues were of meaningful risk, and which were exploited. All of the data used to create this report is available from public data maintained by Red Hat Product Security. | Dec 17 18:39 |
| schestowitz | Red Hat Product Security assigns a Common Vulnerabilities and Exposures (CVE) name to every security issue we fix. If we fix a bug that later turns out to have had a security implication we’ll go back and assign a CVE name to that issue retrospectively. Every CVE fixed has an entry in our public CVE database in the Red Hat Customer Portal as well as a public bug that has more technical detail of the issue. Therefore, for the purposes of this | Dec 17 18:39 |
| schestowitz | report we will equate vulnerabilities to CVEs. | Dec 17 18:39 |
| schestowitz | </p></blockquote></li> | Dec 17 18:39 |
| schestowitz | <li><h5><a href="https://access.redhat.com/blogs/766093/posts/2309211">CVE-2016-3710: QEMU: out-of-bounds memory access issue - Red Hat Customer Portal</a></h5> | Dec 17 18:39 |
| -TechBytesBot/#techbytes- ( status 404 @ https://access.redhat.com/blogs/766093/posts/2309211">CVE-2016-3710 ) | Dec 17 18:39 | |
| schestowitz | <blockquote><p>Quick Emulator (aka QEMU) is an open source systems emulator. It emulates various processors and their accompanying hardware peripherals like disc, serial ports, NIC et al. A serious vulnerability of out-of-bounds r/w access through the Video Graphics Array (VGA) emulator was discovered and reported by Mr Wei Xiao and Qinghao Tang of Marvel Team at 360.cn Inc. This vulnerability is formally known as Dark Portal. In this post we'll see | Dec 17 18:39 |
| schestowitz | how Dark Portal works and its mitigation. | Dec 17 18:39 |
| schestowitz | VGA is a hardware component primarily responsible for drawing content on a display device. This content could be text or images at various resolutions. The VGA controller comes with its own processor (GPU) and its own RAM. Size of this RAM varies from device to device. The VGA emulator in QEMU comes with the default memory of 16 MB. The systems' CPU maps this memory, or parts of it, to supply graphical data to the GPU. | Dec 17 18:39 |
| schestowitz | </p></blockquote></li> | Dec 17 18:39 |
| schestowitz | <li><h5><a href="https://access.redhat.com/blogs/766093/posts/2334141">The Answer is always the same: Layers of Security - Red Hat Customer Portal</a></h5> | Dec 17 18:39 |
| -TechBytesBot/#techbytes- ( status 404 @ https://access.redhat.com/blogs/766093/posts/2334141">The ) | Dec 17 18:39 | |
| schestowitz | <blockquote><p> | Dec 17 18:39 |
| schestowitz | There is a common misperception that now that containers support seccomp we no longer need SELinux to help protect our systems. WRONG. The big weakness in containers is the container possesses the ability to interact with the host kernel and the host file systems. Securing the container processes is all about shrinking the attack surface on the host OS and more specifically on the host kernel. | Dec 17 18:39 |
| schestowitz | seccomp does a great job of shrinking the attack surface on the kernel. The idea is to limit the number of syscalls that container processes can use. It is an awesome feature. For example, on an x86_64 bit machine, there are around 650 system calls. If the Linux Kernel has a bug in any one of these syscalls, a process could get the kernel to turn off security features and take over the system, i.e. it would break out of confinement. If your | Dec 17 18:39 |
| schestowitz | container does not run 32 bit code, you can turn on seccomp and eliminate all x86 syscalls, basically cutting the number of syscalls in half. This means that if the kernel had a bug in a 32 bit syscall that allowed the process to take over the system, this syscall would not be available to the processes in your container, and the container would not be able to break out. We also eliminate a lot of other syscalls that we do not expect processes | Dec 17 18:39 |
| schestowitz | inside of a container to call. | Dec 17 18:39 |
| schestowitz | </p></blockquote></li> | Dec 17 18:39 |
| schestowitz | <li><h5><a href="https://access.redhat.com/blogs/766093/posts/2978671">Changes coming to TLS: Part Two</a></h5> | Dec 17 18:39 |
| -TechBytesBot/#techbytes- ( status 404 @ https://access.redhat.com/blogs/766093/posts/2978671">Changes ) | Dec 17 18:39 | |
| schestowitz | <blockquote><p>In the first part of this two-part blog we covered certain performance improving features of TLS 1.3, namely 1-RTT handshakes and 0-RTT session resumption. In this part we shall discuss some security and privacy improvements. | Dec 17 18:39 |
| schestowitz | </p></blockquote></li> | Dec 17 18:39 |
| *DaemonFC has quit (Quit: Leaving) | Dec 17 18:52 | |
| *tech_exorcist has quit (Quit: see you on Sunday afternoon or Monday afternoon/late morning) | Dec 17 19:37 | |
| *u-amarsh04 (~amarsh04@t25x9hgy9xhrc.irc) has joined #techbytes | Dec 17 20:23 | |
| *u-amarsh04 has quit (connection closed) | Dec 17 20:48 | |
| *leah has quit (Ping timeout: 2m30s) | Dec 17 20:53 | |
| *leah (~leah@wrh2nipuzrd3y.irc) has joined #techbytes | Dec 17 20:53 | |
| *DaemonFC (~daemonfc@nz6epsa2ajwa8.irc) has joined #techbytes | Dec 17 23:04 | |
Generated by irclog2html.py 2.6 | ䷉ find the plain text version at this address (HTTP) or in Gemini (how to use Gemini) with a full GemText version.