数千用 Rust 开发的项目面临拒绝服务攻击

Rust Hyper 包是一个非常流行的处理 HTTP 请求的 Rust 库。安全研究人员发现，大量包含 Hyper 的项目容易受到精心设计的 HTTP 请求引起的拒绝服务攻击，漏洞源于在使用 Hyper 库时忘记对 HTTP 请求设置适当的限制。目前，Rust 的包存储库 crates.io 中列出的 2,579 个项目依赖于 Hyper，下载量已超过 6700 万次，但大量项目尚未回应修复的消息。

消息来源：The Register

老王点评：并不是使用了 Rust 就高枕无忧了，还是会有各种其他的安全漏洞。

美国最幸福、压力最小的工作是伐木工和农民

根据美国劳工统计局的调查，农业、伐木业和林业在所有主要行业类别中具有最高的自我报告的幸福水平，以及最低的自我报告的压力水平。压力最大的行业是包括金融和保险在内的行业，其次是教育和专业和技术行业。

消息来源：华盛顿邮报

老王点评：看看手里的键盘，突然不香了。

苹果公司因非法获取用户数据而被罚

法国数据保护机构 CNIL 周三对苹果公司处以 800 万欧元的罚款。CNIL 称，苹果公司未能 “在将用于广告目的的标识符存入法国 iPhone 用户（iOS 14.6 版本）的终端之前获得他们的同意”。在运行较低版本的 iOS 的 iPhone 中，苹果的个性化广告隐私设置是默认打开的。较新版本的 iPhone 操作系统已纠正了这一问题。

消息来源：Gizmodo

老王点评：虽然苹果公司在隐私方面已经算是不错了，但是也难免会有这种有意无意的错误。

这是一个演示如何创建 POSIX 兼容的间隔定时器的教程。

对开发人员来说，定时某些事件是一项常见任务。定时器的常见场景是看门狗、任务的循环执行，或在特定时间安排事件。在这篇文章中，我将演示如何使用 timer\_create(...) 创建一个 POSIX 兼容的间隔定时器。

你可以从 GitHub 下载下面样例的源代码。

准备 Qt Creator

我使用 Qt Creator 作为该样例的 IDE。为了在 Qt Creator 运行和调试样例代码，请克隆 GitHub 上的仓库，打开 Qt Creator，在 “ 文件 File -> 打开文件或项目…… Open File or Project... ” 并选择 “CMakeLists.txt”：

在 Qt Creator 中打开项目

选择工具链之后，点击 “ 配置项目 Configure Project ”。这个项目包括三个独立的样例（我们在这篇文章中将只会用到其中的两个）。使用绿色标记出来的菜单，可以在每个样例的配置之间切换，并为每个样例激活在终端运行 “ 在终端中运行 Run in terminal ”（用黄色标记）。当前用于构建和调试的活动示例可以通过左下角的“ 调试 Debug ” 按钮进行选择（参见下面的橙色标记）。

项目配置

线程定时器

让我们看看 simple_threading_timer.c 样例。这是最简单的一个。它展示了一个调用了超时函数 expired 的间隔定时器是如何被创建的。在每次过期时，都会创建一个新的线程，在其中调用函数 expired：

#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <signal.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>

void expired(union sigval timer_data);

pid_t gettid(void);

struct t_eventData{
    int myData;
};

int main()
{
    int res = 0;
    timer_t timerId = 0;

    struct t_eventData eventData = { .myData = 0 };

    /*  sigevent 指定了过期时要执行的操作  */
    struct sigevent sev = { 0 };

    /* 指定启动延时时间和间隔时间 
    * it_value和it_interval 不能为零 */

    struct itimerspec its = {   .it_value.tv_sec  = 1,
                                .it_value.tv_nsec = 0,
                                .it_interval.tv_sec  = 1,
                                .it_interval.tv_nsec = 0
                            };

    printf("Simple Threading Timer - thread-id: %d\n", gettid());

    sev.sigev_notify = SIGEV_THREAD;
    sev.sigev_notify_function = &amp;expired;
    sev.sigev_value.sival_ptr = &amp;eventData;

    /* 创建定时器 */
    res = timer_create(CLOCK_REALTIME, &amp;sev, &amp;timerId);

    if (res != 0){
        fprintf(stderr, "Error timer_create: %s\n", strerror(errno));
        exit(-1);
    }

    /* 启动定时器 */
    res = timer_settime(timerId, 0, &amp;its, NULL);

    if (res != 0){
        fprintf(stderr, "Error timer_settime: %s\n", strerror(errno));
        exit(-1);
    }

    printf("Press ETNER Key to Exit\n");
    while(getchar()!='\n'){}
    return 0;
}

void expired(union sigval timer_data){
    struct t_eventData *data = timer_data.sival_ptr;
    printf("Timer fired %d - thread-id: %d\n", ++data->myData, gettid());
}

这种方法的优点是在代码和简单调试方面用量小。缺点是由于到期时创建新线程而增加额外的开销，因此行为不太确定。

中断信号定时器

超时定时器通知的另一种可能性是基于 内核信号。内核不是在每次定时器过期时创建一个新线程，而是向进程发送一个信号，进程被中断，并调用相应的信号处理程序。

由于接收信号时的默认操作是终止进程（参考 signal 手册页），我们必须要提前设置好 Qt Creator，以便进行正确的调试。

当被调试对象接收到一个信号时，Qt Creator 的默认行为是：

• 中断执行并切换到调试器上下文。
• 显示一个弹出窗口，通知用户接收到信号。

这两种操作都不需要，因为信号的接收是我们应用程序的一部分。

Qt Creator 在后台使用 GDB。为了防止 GDB 在进程接收到信号时停止执行，进入 “ 工具 （ Tools ） -> 选项 Options ” 菜单，选择 “ 调试器 Debugger ”，并导航到 “ 本地变量和表达式 Locals & Expressions ”。添加下面的表达式到 “ 定制调试助手 Debugging Helper Customization ”：

handle SIG34 nostop pass

Sig 34 时不停止

你可以在 GDB 文档 中找到更多关于 GDB 信号处理的信息。

接下来，当我们在信号处理程序中停止时，我们要抑制每次接收到信号时通知我们的弹出窗口:

Signal 34 弹出窗口

为此，导航到 “GDB” 标签并取消勾选标记的复选框:

定时器信号窗口

现在你可以正确的调试 signal_interrupt_timer。真正的信号定时器的实施会更复杂一些：

#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>
#include <signal.h>
#include <time.h>
#include <unistd.h>
#include <errno.h>
#include <string.h>

#define UNUSED(x) (void)(x)

static void handler(int sig, siginfo_t *si, void *uc);
pid_t gettid(void);

struct t_eventData{
    int myData;
};

int main()
{
    int res = 0;
    timer_t timerId = 0;

    struct sigevent sev = { 0 };
    struct t_eventData eventData = { .myData = 0 };

    /* 指定收到信号时的操作 */
    struct sigaction sa = { 0 };

    /* 指定启动延时的时间和间隔时间 */
    struct itimerspec its = {   .it_value.tv_sec  = 1,
                                .it_value.tv_nsec = 0,
                                .it_interval.tv_sec  = 1,
                                .it_interval.tv_nsec = 0
                            };

    printf("Signal Interrupt Timer - thread-id: %d\n", gettid());

    sev.sigev_notify = SIGEV_SIGNAL; // Linux-specific
    sev.sigev_signo = SIGRTMIN;
    sev.sigev_value.sival_ptr = &amp;eventData;

    /* 创建定时器 */
    res = timer_create(CLOCK_REALTIME, &amp;sev, &amp;timerId);

    if ( res != 0){
        fprintf(stderr, "Error timer_create: %s\n", strerror(errno));
        exit(-1);
    }

    /* 指定信号和处理程序 */
    sa.sa_flags = SA_SIGINFO;
    sa.sa_sigaction = handler;

    /* 初始化信号 */
    sigemptyset(&amp;sa.sa_mask);

    printf("Establishing handler for signal %d\n", SIGRTMIN);

    /* 注册信号处理程序 */
    if (sigaction(SIGRTMIN, &amp;sa, NULL) == -1){
        fprintf(stderr, "Error sigaction: %s\n", strerror(errno));
        exit(-1);
    }

    /* 启动定时器 */
    res = timer_settime(timerId, 0, &amp;its, NULL);

    if ( res != 0){
        fprintf(stderr, "Error timer_settime: %s\n", strerror(errno));
        exit(-1);
    }

    printf("Press ENTER to Exit\n");
    while(getchar()!='\n'){}
    return 0;
}

static void
handler(int sig, siginfo_t *si, void *uc)
{
    UNUSED(sig);
    UNUSED(uc);
    struct t_eventData *data = (struct t_eventData *) si->_sifields._rt.si_sigval.sival_ptr;
    printf("Timer fired %d - thread-id: %d\n", ++data->myData, gettid());
}

与线程定时器相比，我们必须初始化信号并注册一个信号处理程序。这种方法性能更好，因为它不会导致创建额外的线程。因此，信号处理程序的执行也更加确定。缺点显然是正确调试需要额外的配置工作。

总结

本文中描述的两种方法都是接近内核的定时器的实现。不过，即使 timer\_create(...) 函数是 POSIX 规范的一部分，由于数据结构的细微差别，也不可能在 FreeBSD 系统上编译样例代码。除了这个缺点之外，这种实现还为通用计时应用程序提供了细粒度控制。

via: https://opensource.com/article/21/10/linux-timers

作者：Stephan Avenwedde 选题：lujun9972 译者：FigaroCao 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

一个开源助手可以取代谷歌助理、Alexa 和 Siri？

Home Assistant 是一个开源的智能家居平台，专注于为用户提供本地控制和隐私。它可以从树莓派或甚至本地服务器上运行。

他们还有一个订阅服务，可以获得额外的功能，如支持 Alexa 和谷歌助理，它由一家名为 “Nabu Casa” 的公司管理。

? 该公司由 Home Assistant 的创始人 Paulus Schoutsen 领导。

在上周的 博客 中，Paulus 宣布了一个新的开源项目，旨在提供一个没有主动互联网连接的语音助手，也无需任何其他大型科技公司的语音助手。

这是 一个对谷歌助理、Alexa 和 Siri 的开源挑战者？ ?

让我们看看这到底是怎么回事。

它是什么？ 这将是 Home Assistant 应用的一部分，将提供在本地运行语音命令的能力，以控制连接的智能设备。

Paulus 还断言，他们最重要的优先事项是支持不同的语言，他说：

人们需要能够用自己的语言说话，因为对于智能家居的语音助手来说，这是最容易接受和唯一可以接受的语言。

为了推动这一努力，Rhasspy 的创造者 Mike Hansen 已经被拉来实现这一目标。

对于那些不知道的人来说，Rhasspy 是另一个开源软件，专门提供一个由其用户社区支持的完全离线的语音助手。

如果你问我，我觉得 Home Assistant 的这个功能将由 Rhasspy 提供，这是一件好事。

为什么要重新发明已经存在的东西？最好是在它的基础上进行改进。

可以期待什么？ 最初，这个语音助手做不到做你可能期待的事情。因此，像进行网络搜索、打电话、玩语音游戏等，都是不可能的。

它所关注的反而是语音助手应该有的基本功能。这样做是为了确保他们面前的工作是可控的。

他们的目标是从几个动作开始，然后围绕它们建立语言模型。

在目前的状态下，Home Assistant 在其用户界面上支持 62 种不同的语言。他们计划用他们的语音助手增加对所有这些语言的支持。

何时期待？ 他们已经开始了这方面的工作，为每种语言建立一个 意图匹配句子集合。

这意味着社区可以通过将智能设备的命令改编成各自的母语，来为语音助手的发展做出贡献。

他们的目标是在 2023 年的某个时候发布，并提到这将是“语音年”。

我认为一个可以离线工作的开源语音助手可以是一个非常有用的东西。它可以让你不受大科技公司的任何追踪。

? 还有一个额外的好处是，它的开发背后有一个庞大的社区，有什么理由不喜欢呢？

via: https://news.itsfoss.com/open-source-assistant/

作者：Sourav Rudra 选题：lkxed 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

ChatGPT 已被利用创建恶意代码和黑客攻击

在一个流行的地下黑客论坛上突然出现了一篇题为 “ChatGPT —— 恶意软件的好处” 的帖子，作者说他们正在用 ChatGPT 进行实验，以重新创建常见的恶意软件和技术。虽然目前所展示的还比较初级，但这只是一个时间问题。之前，ChatGPT 因生成错误的代码，而被 Stack Overflow 禁止了由其生成的回答。但该技术正在改进，上个月芬兰政府的一份报告警告说，人工智能系统已经被用于社会工程，并在五年内可能极大地增加攻击量。

消息来源：The Register

老王点评：这为广大脚本小子打开了一扇新的大门。果然任何新技术都会被先投入到非法用途。

Adobe 将默认使用你的作品来训练其人工智能算法

有人在 Adobe 创意云服务的隐私和个人数据账户设置中发现，“它可能使用机器学习等技术分析你的内容（例如用于模式识别），以开发和改进其产品和服务”。用户自动允许 Adobe 访问他们的数据，除非他们选择退出该服务。该条款于去年 8 月更新，适用于存储在其云服务器上的图像、音频、视频、文本或文件。但 Adobe 回应称，“该政策不是新的，已经存在了十年，以帮助我们为客户提高产品。…… Adobe 不会使用存储在客户的创意云账户上的任何数据，来训练其实验性的生成性人工智能功能。”

消息来源：The Register

老王点评：新的人工智能进步，给包括创意界在内的各行各业都带来了挑战。

Linux 4.9 结束了 6 年的支持

Linux 4.9 LTS 内核发布于 2016 年，Greg 今天宣布了它的最后一个点版本 Linux 4.9.337。下一个将结束支持的是 2014 年 1 月到期的 Linux 4.14 LTS，以及 2024 年底的 Linux 4.19 LTS 等等。Linux 5.15 LTS 目前计划在明年 10 月到期，但如果有足够的兴趣/使用量，可能会从两年的 LTS 支持周期延长到六年。同时，Linux 6.1 预计将成为 2022 年的 LTS 内核版本，尽管还没有正式宣布。

消息来源：Phoronix

老王点评：没想到 Linux 4.9 都已经支持了 6 年了。

回音

• 之前我们 报道 过，Windows 7 和 8 的支持在 1 月彻底结束，下周二，它们将接收到最后一批安全补丁。

Budgie 10.7 有很多有价值的改进。请看本文。

Budgie 是一个旨在将杂乱无章降到最低，为用户提供一个干净/简约的体验的桌面环境。

早在 2022 年 1 月，Solus 的前联合负责人 Joshua Strobl 离开了 Solus，从事 SerpentOS 的开发，但他还继续参与 Budgie 的开发。

因此，他将该项目复刻到一个新的代码仓库，并成立了 Buddies Of Budgie 组织。三个月后，他们发布了 Budgie 10.6。

这是一个很不错的版本，即使不是很特别。

展望未来，他们发布了 2023 年的计划，其中包括发布 Budgie 10.7。

Joshua Strobl 在博文中也提到了更多计划内容：

至少，它应该是一个很好的基础，并为 Budgie 桌面今年的发展方向提供一个清晰的蓝图：Budgie 10.x 将会增加新的功能、QoL 改进和修复。Budgie 11 的开发工作也将起步。

Budgie 10.7 可以期待什么？

Budgie 10.7 的开发工作自去年以来一直在进行。它本应在 2022 年发布，但需要更多的时间来提供一个完美的体验。

已经完成了很多工作，但其中一些值得注意的三个变化是：

• 对 Budgie 菜单的更新
• 新的 Budgie 屏幕截图工具
• 对 Budgie 运行对话框的改进

对 Budgie 菜单的更新

在这个版本中，Budgie 菜单将得到一些改进，例如。

• 一个新的电源菜单，包含所有常用的选项，如暂停、休眠、注销和关闭电源。
• 更新的个人用户菜单可以快速访问 XDG 目录。这将让你直接打开文件管理器窗口进入主页、文档、音乐等文件夹。
• 快速访问 Budgie 控制中心和桌面设置。
• 能够从菜单本身显示各种桌面设置。

Budgie 屏幕截图工具

终于，你不再需要下载另一个工具来在 Budgie 上进行截图；从 10.7 开始，它将具有一个原生的屏幕截图应用程序。

它将支持对屏幕、窗口的捕捉，甚至是进行选区捕捉。

对 Budgie 运行对话框的改进

Budgie 运行对话框将获得许多改进，例如：

• 一个新的应用程序索引器将被用于 Budgie 菜单，以寻找和分类应用程序。它应该能提供一个 “可预测的模糊搜索体验”。
• 根据显示器的工作区域改进对话框的大小计算。
• 更好的应用程序名称和描述的标签样式。

发布和未来计划

根据他们的 公告，他们打算在 2023 年第一季度的某个时候发布 Budgie 10.7。他们还没有确定一个具体的日期。

并计划在不久之后发布带有错误修复的 10.7.1 版本，然后在 2023 年第二季度发布 Budgie 10.8。

via: https://news.itsfoss.com/budgie-10-7-features/

作者：Sourav Rudra 选题：lkxed 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

作为一个偏爱 在桌面电脑上使用 Linux，并鼓励使用开源软件的人，你可能期待就标题中提出的问题得到一个响亮的肯定回答。

然而，我并不打算仅限于讨论开源软件的优点。让我们一起探索更多观点！

在本文，我计划分享我关于开源软件是否安全的思考，以及哪些事情与开源软件的安全性相关。

为什么你需要关注开源软件是否安全？

不论你是使用 Linux 系统还是使用其他类型的操作系统，你都会在某种程度上（直接地/间接地）被开源软件所包围。

举个例子，大多数专有软件工具依赖于某种形式的开源库来保证其正常工作。

此外，各种规模的公司（包括谷歌、微软和 Facebook）依赖开源软件或者以某种途径向开源社区贡献资源是有原因的。

因此，开源软件的安全性是有必要了解的。

有关开源软件安全性的迷思

虽然有多种理由证明开源软件在安全性方面的缺陷，然而其中一些实际毫无意义。

任何人都可以查看并恶意利用开源软件代码

是的，开源软件代码对于任何人都是可访问的。但是你可以查看代码并不意味着你可以利用它。

不现实。

即使任何人都可以复刻（或者拷贝）该软件，原始软件也不能轻易地被修改使用。

通常，项目维护人员（或者维护团队）管理代码仓库，并且接受来自贡献者的提交。开源软件代码在接受之前会被审查。没有人可以就这样劫持代码。

不论是开源软件还是闭源软件，攻击者都需要付出努力来利用软件中的代码漏洞或者添加恶意代码。

没有专职团队，安全性无从谈起

很多人相信如果开源软件没有专职人员或者专职团队，维护软件安全性是困难的。

恰恰相反，由于各种各样类型的贡献者的加入与离开，开源软件获得了来自更大范围的开发者的更多关注。

他们可能比由专有软件所聘用的少数开发者更能够发现安全问题。

一些来自 Mozilla 等同类公司的项目拥有自己的专职团队来高效处理安全问题。同样的，大部分成功的开源项目拥有大量的资源用于保障安全性。

因此，开源软件的生态系统是安全性的组合包。即使没有专职团队，开源项目也可以得到来自各类贡献者的帮助，他们中的一些很大程度上是有利可图的，这有助于他们投入更多的精力。

开源软件是安全的，以下是原因

既然我们已经澄清了这些有关开源软件安全性的迷思，让我重点展示一下开源软件是如何处理安全问题的。

换句话说，开源软件在安全性上的优势。

请不要忘记，开源软件的优势也是 Linux 比 Windows 更好 的一些原因。

更多的眼晴关注开源软件代码

不像专有软件，（对开源软件的）代码访问并不局限于少数几个开发者。

一些开源项目甚至可能拥有数以万记的开发者可以查看代码、审查它们并标记和修复其中的安全性问题。

相比闭源软件，这给予了开源项目拥有快速识别问题并尽快修复它们的能力的优势。

不仅仅限于拥有更多的开发者，企业通常也会参与他们所使用的开源项目。当他们这样做的时候，他们也会查阅代码并审查它们。

这提供了另一条外部审查的途径，而这可能有助于提升开源软件的安全性。

反之，就闭源软件而言，数量有限的开发者可能并不能找出所有种类的安全问题。而且他们可能需要花费更长的时间来一一修复发现的问题。

社区决定安全问题的优先级

闭源软件的开发者可能在处理什么问题和什么时候解决问题等方面有某些限制或者优先等级。

而如果是开源项目，贡献者社区可以自行决定优先级，并自行安排他们想解决的问题以及决定合适修复问题。你不需要依赖于供应商的决定或者按照他们的指示来解决一个安全问题。

着手处理和修复安全问题的决策在开源软件项目中更加透明和灵活。因此，它可以被证明是更有效的，并为你带来以下三个益处：

• 透明度
• 不依赖供应商
• 更快的安全更新

开源软件不是防弹的，以下是原因

虽然在某些情况下，开源软件可能在安全性上具有优势，然而仍有一些因素影响它。

承认这些问题的存在是很重要的，据此，企业或者个人可以就开源软件的安全情况做出更好的决定。

并无足够的眼睛来审查代码和不确定性

即使开源软件代码可以被全世界的开发者自由访问，项目没有足够的贡献者/开发者彻底审查开源代码的可能性仍然存在。

既如此，我们不能对开源软件的同行审查抱有极高的信心，因为它恰好缺失了这一点。

开源软件可能“声称”拥有最高的安全性因为它们是开源的。在没有足够的开发者致力于该项目时，这是一种误导。

同样，我们也无从得知有多少开发者在查看/检查代码，也不知道代码的检查进行到什么程度了。

举例而言， 心脏出血漏洞 Heartbleed 是在一个被广泛使用的项目（OpenSSL）中引入了 2 年以后才被发现的。

软件责任与问责

对于个人用户这可能并不重要，但是开源项目通常并无任何保证。

因此，如果一家公司使用它，它们必须自行承担任何由该软件使用造成的数据丢失与损坏。

这告诉你，没有什么是 100% 安全和没有漏洞的。无论有多少眼睛聚焦在代码上或者贡献者的技术多么精湛，总会存在某种形式的风险，无论是安全风险还是数据丢失。

这告诉我们一个现实：开源软件并非防弹的。

开源软件有其更高安全性的优势，但是...

就安全性而言没有什么优胜者。不论是闭源还是开源，当涉及安全问题时都适用同一套原则。

有很多外部因素可以影响软件安全性，而其中很多因素并不依赖于源代码。

必须以某种形式监控代码，以保证安全。

是的，开源道路提供了闭源软件所不具备的优势，但是这并不意味着开源软件是防弹的。

你对开源软件安全状况有何思考？你又是否认为开源软件比专有软件解决方案更好呢？

提前感谢你在下面的评论中提出的宝贵意见。

via: https://news.itsfoss.com/open-source-software-security/

作者：Ankush Das 选题：lujun9972 译者：CanYellow 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出