Компания Qualys выявила ещё одну критическую уязвимость (CVE-2020-8794) в почтовом сервере OpenSMTPD, развиваемом проектом OpenBSD. Как и выявленная в конце января уязвимость, новая проблема даёт возможность удалённо выполнить произвольные команды shell на сервере с правами пользователя root. Уязвимость устранена в выпуске OpenSMTPD 6.6.4p1...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=52423

• Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним, 23:46 , 24-Фев-20
  • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,uberHacker, 00:57 , 25-Фев-20
    • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,заминированный тапок, 08:35 , 25-Фев-20
  • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Дон Ягон, 03:44 , 25-Фев-20
    • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,zurapa, 09:08 , 25-Фев-20
      • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,лютый жабби, 09:57 , 25-Фев-20
        • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,б.б., 09:59 , 25-Фев-20
          • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,zurapa, 13:15 , 25-Фев-20
        • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,пох., 10:11 , 25-Фев-20
          • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,evkogan, 10:36 , 25-Фев-20
            • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,привет, 10:46 , 25-Фев-20
              • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,evkogan, 11:07 , 25-Фев-20
              • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,пох., 12:18 , 25-Фев-20
              • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним, 12:46 , 25-Фев-20
              • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,2Lazy, 17:47 , 25-Фев-20
                • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,пох., 20:30 , 25-Фев-20
            • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,пох., 12:34 , 25-Фев-20
              • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним, 13:04 , 25-Фев-20
                • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,пох., 13:27 , 25-Фев-20
                  • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним, 14:45 , 25-Фев-20
                    • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,пох., 15:57 , 25-Фев-20
                      • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,лютый жабби__, 18:04 , 25-Фев-20
                        • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,пох., 18:33 , 25-Фев-20
              • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,evkogan, 18:02 , 25-Фев-20
                • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,пох., 18:52 , 25-Фев-20
          • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,anonymous, 11:33 , 25-Фев-20
            • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,пох., 12:23 , 25-Фев-20
        • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,zurapa, 13:13 , 25-Фев-20
        • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,2Lazy, 17:37 , 25-Фев-20
          • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,пох., 18:56 , 25-Фев-20
      • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,лютый жабби, 09:58 , 25-Фев-20
        • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,zurapa, 13:11 , 25-Фев-20
      • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним, 11:47 , 26-Фев-20
        • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,zurapa, 05:36 , 27-Фев-20
  • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,ПерлухаБратуха, 11:53 , 25-Фев-20
• Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним, 23:54 , 24-Фев-20
• Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним, 00:00 , 25-Фев-20
  • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,fske, 00:20 , 25-Фев-20
    • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним, 00:27 , 25-Фев-20
      • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,пох., 12:39 , 25-Фев-20
    • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,пох., 10:22 , 25-Фев-20
      • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,крок, 13:32 , 25-Фев-20
  • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним, 00:23 , 25-Фев-20
    • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним, 01:41 , 25-Фев-20
• Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,pin, 00:16 , 25-Фев-20
  • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,б.б., 08:24 , 25-Фев-20
  • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,zurapa, 09:20 , 25-Фев-20
    • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,б.б., 09:27 , 25-Фев-20
    • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,pin, 09:44 , 25-Фев-20
      • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,zurapa, 10:36 , 25-Фев-20
        • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,pin, 10:45 , 25-Фев-20
          • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,zurapa, 12:58 , 25-Фев-20
      • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,zurapa, 13:28 , 25-Фев-20
        • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,pin, 14:40 , 25-Фев-20
          • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,zurapa, 16:17 , 25-Фев-20
          • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,zurapa, 16:38 , 25-Фев-20
            • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,pin, 17:11 , 25-Фев-20
              • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,pin, 17:18 , 25-Фев-20
                • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним, 20:18 , 25-Фев-20
                • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,ssh, 01:25 , 26-Фев-20
                  • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,pin, 12:11 , 26-Фев-20
                    • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,ssh, 16:42 , 26-Фев-20
                      • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,pin, 20:38 , 26-Фев-20
              • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,zurapa, 08:50 , 27-Фев-20
    • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним, 11:14 , 25-Фев-20
    • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним, 13:10 , 25-Фев-20
      • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,юникснуб, 13:29 , 25-Фев-20
      • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,ssh, 01:16 , 26-Фев-20
        • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним, 12:56 , 26-Фев-20
    • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Ананимас008, 01:16 , 26-Фев-20
• Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,pin, 00:18 , 25-Фев-20
  • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним, 01:41 , 25-Фев-20
    • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,пох., 13:36 , 25-Фев-20
• Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Ананимус, 00:19 , 25-Фев-20
• Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним, 00:26 , 25-Фев-20
  • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Ivan_83, 00:46 , 25-Фев-20
    • stdlib,Аноним, 01:34 , 25-Фев-20
      • stdlib,leap42, 03:01 , 25-Фев-20
      • stdlib,Аноним84701, 13:29 , 25-Фев-20
      • stdlib,Ivan_83, 17:03 , 10-Мрт-20
    • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним, 01:44 , 25-Фев-20
      • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,КО, 08:43 , 25-Фев-20
        • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним, 13:19 , 25-Фев-20
          • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,пох., 21:45 , 25-Фев-20
      • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним, 10:11 , 25-Фев-20
        • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним, 13:26 , 25-Фев-20
      • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Ivan_83, 17:01 , 10-Мрт-20
  • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним84701, 13:32 , 25-Фев-20
  • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним, 13:34 , 25-Фев-20
    • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним84701, 13:58 , 25-Фев-20
      • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним, 15:49 , 25-Фев-20
• Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Дон Ягон, 03:41 , 25-Фев-20
  • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,ssh, 04:25 , 25-Фев-20
  • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним, 10:37 , 25-Фев-20
    • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним, 12:19 , 25-Фев-20
      • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним, 13:18 , 25-Фев-20
        • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,юникснуб, 13:33 , 25-Фев-20
          • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним, 14:20 , 25-Фев-20
        • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,zurapa, 14:47 , 25-Фев-20
• Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,suffix, 07:44 , 25-Фев-20
  • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,pin, 09:48 , 25-Фев-20
    • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,suffix, 09:55 , 25-Фев-20
      • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,evkogan, 10:49 , 25-Фев-20
        • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,suffix, 10:55 , 25-Фев-20
          • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,pin, 12:12 , 25-Фев-20
            • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,suffix, 12:15 , 25-Фев-20
              • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,pin, 12:50 , 25-Фев-20
                • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,evkogan, 18:05 , 25-Фев-20
          • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Ю.Т., 23:04 , 25-Фев-20
      • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним, 12:21 , 25-Фев-20
  • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним, 14:47 , 25-Фев-20
    • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним, 20:47 , 25-Фев-20
    • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,suffix, 23:32 , 25-Фев-20
• Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,б.б., 08:23 , 25-Фев-20
  • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,suffix, 15:32 , 25-Фев-20
• Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,б.б., 08:24 , 25-Фев-20
  • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним, 13:28 , 25-Фев-20
• Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Ю.Т., 08:29 , 25-Фев-20
  • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,evkogan, 11:01 , 25-Фев-20
    • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Ю.Т., 11:10 , 25-Фев-20
      • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,evkogan, 11:34 , 25-Фев-20
        • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Ю.Т., 16:40 , 25-Фев-20
    • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,пох., 12:49 , 25-Фев-20
      • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Ю.Т., 16:49 , 25-Фев-20
        • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,пох., 19:07 , 25-Фев-20
          • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Ю.Т., 23:01 , 25-Фев-20
    • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Тот самый, 13:03 , 25-Фев-20
  • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним, 13:02 , 26-Фев-20
    • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,xm, 14:32 , 27-Фев-20
• Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Вебмакака, 08:39 , 25-Фев-20
  • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,б.б., 08:48 , 25-Фев-20
    • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Вебмакака, 09:38 , 25-Фев-20
• Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Нанобот, 09:02 , 25-Фев-20
• Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,ryoken, 09:37 , 25-Фев-20
  • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,б.б., 09:40 , 25-Фев-20
    • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним, 10:44 , 25-Фев-20
• Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,DerRoteBaron, 09:52 , 25-Фев-20
  • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,б.б., 10:17 , 25-Фев-20
    • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,пох., 12:52 , 25-Фев-20
  • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,пох., 12:53 , 25-Фев-20
• Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,б.б., 10:21 , 25-Фев-20
• Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,б.б., 10:21 , 25-Фев-20
  • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,suffix, 10:30 , 25-Фев-20
    • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним, 13:30 , 25-Фев-20
      • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,пох., 13:39 , 25-Фев-20
• Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,xm, 13:13 , 25-Фев-20
  • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,юникснуб, 13:38 , 25-Фев-20
    • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,пох., 13:43 , 25-Фев-20
      • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,ssh, 01:36 , 26-Фев-20
        • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,пох., 10:56 , 26-Фев-20
          • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,ssh, 11:11 , 26-Фев-20
    • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним, 14:30 , 25-Фев-20
      • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Аноним, 14:38 , 25-Фев-20
  • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,zurapa, 15:07 , 25-Фев-20
    • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,xm, 16:14 , 25-Фев-20
      • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,zurapa, 16:40 , 25-Фев-20
    • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,ssh, 06:20 , 26-Фев-20
• Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,snmp agent, 20:02 , 25-Фев-20
• Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Denis Fateyev, 01:08 , 26-Фев-20
  • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,юникснуб, 16:29 , 01-Мрт-20
    • Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Denis Fateyev, 20:00 , 03-Мрт-20
• Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,Дон Ягон, 02:20 , 27-Фев-20
• Уязвимости в OpenSMTPD, позволяющие удалённо и локально полу...,zurapa, 07:33 , 06-Май-20

понятно. обратно на postfix.

Так так так, что тут у нас, а?

The Postfix implementation uses safe subsets of the C language and of the POSIX system API.

Хаха, удачи!

смузи не пролей

> понятно. обратно на postfix.

При всём уважении к разработчикам OpenSMTPD, если бы у меня в продакшене уже был бы postfix, я не стал бы просто так, без наличия каких-то очень сильных причин (которые я сходу придумать не могу) менять его на OpenSMTPD.

Зачем, если не секрет, вообще было уходить с postfix на OpenSMTPD?

За тем, что конфигурация OpenSMTPD на порядке проще и удобней в общем ключе конфигурирования в OpenBSD. И если вы уж сели на OpenBSD и вам понравилось, как там устроен синтаксис конфигурационных файлов сервисов, то OpenSMTPD вам также будет в разы приятней. Особенно, если это малые конфигурации.

Конечно, я понимаю, что "приятней, удобней" - это субъективные, так себе доводы. Но всё же. Допустив в Postfix мониторить отправку получение писем, очереди, это не совсем прозрачный метод. А OpenSMTPD имеет команды позволяющие сразу смотреть очередь. В Postfix авторизация, это вообще костыль со стороны прикручиваемый отдельно. В OpenSMTPD это в рамках самого сервиса с весьма устойчивым шифрованием паролей. И получается так, что почитав man'ы, только man'ы, ты можешь настроить smtp сервер с большинством причуд, что требуется от сервера. В то время, как в Postfix, это дичайшая куча файлов конфигурации и вариаций, как это можно организовать. И всё эта гибкость, безопасность пугает.

А вот, если вы не эстет, а хипстер со смузи и любите всё чтобы в linux по красоте, да ещё и в docker, и основная информация по конфигурированию сервисов - статьи на хабре, то вам однозначно нет смысла даже смотреть на OpenSMTPD. Это я сейчас не поиздеваться, а как оно получается. В интернете проще наковырять, как настроить Postfix, который к тому же уже идёт из коробки во многих системах. И, почти, любого админа Linux ткнув палкой ночью, можно получить простейшую конфигурацию Postfix. (в конце чуть утрировал для красоты слога).

"конфигурация OpenSMTPD на порядке проще и удобней"
"вы не эстет,"

Отправить бы тебя, эстета, sendmail настраивать ))) постфикс ему сложный. Ну и времена настали...

имеется ввиду это

https://www.opensmtpd.org/presentations/asiabsdcon2013-smtpd...

> имеется ввиду это
> https://www.opensmtpd.org/presentations/asiabsdcon2013-smtpd...

Да! Да! Да! Точно! Благодарю за иллюстрацию! Это шедевр!

> Отправить бы тебя, эстета, sendmail настраивать

настройка sendmail (если его вообще надо зачем-то "настраивать" на васян-хосте) обычно заключается в правке файла из пяти строк не считая комментариев. Но обычно с этим справляется установщик. Если это для вас сложно - вам лучше докер в докере в докере поднимать, а ни в какие bsd не лазить.

И да, в так настроенном сендмэйле не будет open relay, в отличие от васян-настроенных поцфиксов, так и поставляемых по сей день с тщательно замаскированной миной.

Сегодня в очередной раз спам пришел с такого.

Если все что Вам надо в sendmaill - это настроить отправку писем от локальных сервисов на подконтрольный Вам почтовый сервер, причем без любых проверок на стороне сервера, то Вам достаточно поправить всего 1 строчку.
Но Вот если использовать sendmaill как почтовый релай на шлюзе, я на Вас посмотрю с простотой конфигурации.
Не надо сравнивать теплое и твердое.
Сделать openrelay из postfix можно, но это можно сделать с абсолютно любым почтовым сервером.
Мне в свое время очень понравился постфикс сочетанием безопасности, работе под нагрузкой и гибкости (безопасность не потому что нельзя сломать все в конфиге, а для умеющих админить).

а что там сложного? мейлертейбл раскоментировать/добавить,
отредактировать там релеи-домены.
ну и пару строк с простейшими проверками раскоментировать...

сейчас крайне редко надо лезть уже в cf, нет необхадимости

а опен-релай из постфикса, вроде, из коробки распространялся
пофиксили уже?

Для простой конфигурации да, ничего сложного.
А вот не лезть, тут вся соль. Хотя честно я его уже лет 15 не видел.
опен-релай у редхата из коробки не было вроде. За остальных не знаю

> пофиксили уже?

в тех версиях, что идут в актуальных дистрибутивах (у меня, понятно, ни малейшего желания специально качать свежайшее еще дымящееся непосредственно от авторов) - нет ;-)

Они, разумеется, сто лет как исправлены майнтейнерами дистрибутивов (и пакетов в *bsd) - и на тему mynetworks, и на тему вообще не лезть к внешним интерфейсам, пока не потребуется принимать почту, но васян-админы, верующие в неувизгвимость поцфикса, легким движением хвоста сводят все это обратно к $ю - строчек в конфиге много, думать некогда, KPI падают.

Так что у меня он по прежнему на почетном втором месте из тех, кого удается определить. На первом - гугль, понятен.

>а опен-релай из постфикса,
> вроде, из коробки
>распространялся
>пофиксили уже?

Не порите чушь,ей больно.
В постфиксе опенрелей никогда не был разрешен по умолчанию.

Кстати сказать, в моем sendmail.mc для почтового шлюза на несколько доменов осмысленных строк конфигурации всего 37, а если выкинуть непринципиальную настройку таймаутов - 26.

чорт, у меня 99 ;-)
И это не считая того, что в LOCAL_RULESETS только какой-то стремный хак, остальное подцепляется внешним файлом.

Правда, из этой сотни десяток *bl.sorbs.net, от которых давным-давно уже нет никакого толку, пачка танцев вокруг бесполезно-tls, кстати, имейте в виду - у копропротивных mta шлюзов становится нормой копировать худшие практики мурзилы - в смысле, рвать сессию если им что-то не понравится в сертификате, недавно напоролись, ну и всякие RATE_THROTTLE, ибо VRFY у меня можно, а после второй неопознанной команды - досвидос.

А васяно-настраиваемых строк после OSTYPE/DOMAIN как-то и пяти не просматривается.
Каждому ли васяну понадобится mailertable? Не думаю...

> Но Вот если использовать sendmaill как почтовый релай на шлюзе, я на Вас посмотрю с простотой
> конфигурации.

тоже ничего особенного - использую. Перенести весь трэш, накопившийся там за тридцать лет в exim - во-первых, совершенно нечеловеческий труд, во-вторых, он и там останется трэшем, местами получится даже хуже чем было. В postfix не перенесется, разьве что в milter выносить куски логики.
Там не пять строк, но васяну этого и не надо. Единственное мерзкое место, похоже по сей день не решенное - нет простой возможности вставить проверку существования почтового ящика через ldap или еще какой внешний сервер на этапе сессии (а постфактум нахрен не надо так делать). milter, разумеется, спасет.

> Сделать openrelay из postfix можно

но ненужно. Он там из коробки все тридцать лет его существования. Если специально не позаботиться  отключить. То что ты этого до сих пор даже и не знаешь - штамп "п-ц" на твоей квалификации, ага.

Типичный админ опеннета, угу. Они тут почти все такие.

> но ненужно. Он там из коробки все тридцать лет его существования. Если специально не позаботиться  отключить.

Ты postfix "изучил" по комментам здешних гуру? Или openrelay для тебя просто модное ругательство?
За те 18 лет, что я с ним работаю, там никогда не было опенрелея из коробки. Если сдуру его не включить.

> Типичный админ опеннета, угу. Они тут почти все такие.

Ога, и ты не исключение.

перепись местных дурачков. "18 лет работает", про дыру - не в курсе.

А можете списочек своих айпишников заодно прилагать к этой рыгалии, я их превентивно добавлю в reject?

> А можете списочек своих айпишников

127.0.0.0/8

а, блин, беру свои слова назад - установленный на не воткнутый в сеть хост поцфикс, безусловно, не является опенрелеем.

>установленный на не воткнутый в сеть хост поцфикс

по дефолту во всех дистрибах постфикс не релеит, если ты чего-то там включил, дык не пальцы гни, а язык засунь куда-нибудь.

> по дефолту во всех дистрибах постфикс не релеит

да, да, васян зуб дает - он во всех дистрибах лично проверил, тыщах их.

По _дефолту_ поцфикс - релеит.

Что разработчики дистрибутивов за тебя настроили специально не по дефолту - их добрая воля и их квалификация, а не твоя, но я бы не рисковал говорить за всех. Кто-то из них может оказаться не лучше васянов с опеннета.

А поскольку местные васяны даже сейчас, вместо того чтобы посмотреть и подумать, с пеной у рта повторяют мантру "не релеит, не релеит, мне в молитвенном бдении некий ангел это сказал, б.. буду! 15 лет не релеит!" - спама от релеящих постфиксов у меня меньше вряд ли станет.

Прекращайте вешать ярлыки вообще и необоснованные в частности.
В RHEL 4/5/7 версий он из коробки не опен.
Где он у ТЕБЯ опен -релэй разберись сам. Может не надо пользоваться дистрибутивом с такими меинтейнерами. Если имеешь ввиду когда собираешь сам, то меня не интересует.
Я его ни разу не собирал. Зачем если он идет из коробки нормально собранный и еще обновления регулярно прилетают без напряга.

Да и раз уж ты такой спец, в отличии от меня со "штамп "п-ц" на твоей квалификации", то давай я не буду гадать где ты видишь опен-релэй "там из коробки все тридцать лет его существования".
Расшифруй слово там грамотно, как серьезный человек.

> Прекращайте вешать ярлыки вообще и необоснованные в частности.
> В RHEL 4/5/7 версий он из коробки не опен.

из какой еще "коробки"? С конфигами, настроенными за тебя? Да, не опен. Ну так это не заслуга автора, это заслуга разработчиков RHEL.
Но ты-то, походу, даже не в курсе, какая именно настройка за это отвечает? (я, кстати, тоже - их там не одна. У rhel7 довольно опасный метод оверрайда - васян с легкостью необычайной сделает таки relay, про другие не знаю. Попробуй сделать такое с сендмэйлом ?)

> Я его ни разу не собирал. Зачем если он идет из коробки
> нормально собранный и еще обновления регулярно прилетают без напряга.

понятен. Это, если что, не о сборке - собранный он там стандартно. Он там настроенный немного нестандартно.

> где ты видишь опен-релэй "там из коробки все тридцать лет его
> существования".
> Расшифруй слово там грамотно, как серьезный человек.

Расшифровываю: в конфиге по умолчанию, до того как его вручную пооверрайдил грамотный чувак из rhel.

Который ограничил его binding вообще только localhost - и, похоже, у rhel7, попавшей под руку, кроме этой шаткой защиты - никакой другой нет.

У дебианоидов, вроде, чуть лучше, но негде проверить.

Когда последний раз работал с sendmail, конфиг там был вовсе не 5 строчек. А там было куча m4-файлов из которых генерировался весьма себе нехилый конфиг.

там еще "куча" си файлов - их ты тоже каждый раз лезешь ковырять?
(И что характерно - там предусмотрен удобный механизм для этого, для тех кто понимает, что делает)

Твой конфиг - _один_ файл, sendmail.mc - и в нем именно пять строк (в лучшем случае).

> "конфигурация OpenSMTPD на порядке проще и удобней"
> "вы не эстет,"
> Отправить бы тебя, эстета, sendmail настраивать ))) постфикс ему сложный. Ну и
> времена настали...

А вот это уже извращением попахивает. За что вы так со мной?

А вообще да, надо было остановиться ещё на перфокартах, а то понаделали тут технлогий - устанешь изучать.

Кстати сказать, я всю дорогу живу на сендмейле и даже худо-бедно могу разобраться в правилах не только m4, но и основного языка конфигурации - а вот осилить конфиги postfix у меня тяму так и не хватило...

> Кстати сказать, я всю дорогу живу на сендмейле и даже худо-бедно могу
> разобраться в правилах не только m4, но и основного языка конфигурации

Ну, ты же, наверное, ради этого - op.me когда-то прочитал? Современному админу - не потянуть, да и времени столько у него нет. В принципе, ему и незачем - мир стал сильно проще за последние 25 лет, такой сложной многостадийной обработки уже давно не надо.

> - а вот осилить конфиги postfix у меня тяму так и
> не хватило...

так их не надо осиливать - за это горе-админы его и любят.

Каждый параметр в доках ищется раздельно - по мере надобности, если она вообще возникает. Обычно - не возникает. А когда у тебя хитрый релей с миллионами проверок и специальных случаев - ты ставишь exim ;-)

ещё и докер приплёл. постфикс старше то только докера, но похоже и тебя.

Благодарю. Вы мне льстите. Я не столь молод. Хотя, если брать возваст в этой индустрии, то я совсем дитя ещё. Не судите строго, дяденька.

> В то время, как в Postfix, это дичайшая куча файлов конфигурации и вариаций

вообще то всего два - main.cf и master.cf

> А OpenSMTPD имеет команды позволяющие сразу смотреть очередь

postqueue не осилил?

> В Postfix авторизация, это вообще костыль со стороны прикручиваемый отдельно

и правильно, зачем ее пихать в smtp сервер?

Я тут много оправданий придумал. Но в общем ты прав. Ты меня уиграл!

Хватит кудахтать! Уже исправлено - https://ftp.openbsd.org/pub/OpenBSD/patches/6.6/common/021_s...

> уязвимость в почтовом сервере OpenSMTPD, развиваемом проектом OpenBSD
> Уязвимость в гипервизоре VMM, развиваемом OpenBSD

S in BSD stands for Security.

При таком качестве кода OpenBSD, боюсь, что  Qualys доберётся до аудита OpenSSH и бежать станет некуда.

Ну а ты представь, на минуту, что твоя теория верна про качество openssh. А еще представь, что вход(ы) с задней стороны уже давно найдены (не)хорошими людями. Стоит бежать или ну ее нах.. эту экстраполяцию?

> с задней стороны уже давно найдены (не)хорошими людями

Ну так Сноуден же где-то в своих интервью говорил, что у них там в АНБ специальный отдел занимается поиском багов в разных ОС и копит себе материал (типа эксплойты, 0-day и тп). Если OpenBSD такое рeшeтo, то поди у них много чего накопилось на неуловимых джо.

если бы он был только у них - я бы и спал спокойно, но, подозреваю, такой "специальный отдел" у любого васяна, пока вуз не закончил, пама с мамой кормят, и кроме сессии других занятий нет.

И кто-то уже вполне мог отложить себе найденную 0day на будущее.

к сожалению, можно не представлять  - его теория абсолютно верна, качество кода openssh, и особенно - кода наляпанного последние десять лет, именно такое. Держится он только на том что ядро украдено у хорошего программиста, не имевшего ни малейшего отношения к openbsd, а криптография - openssl (худо-бедно латаемый), причем используется только криптографическая часть от него, а не вечнодырявая сетевая. (Насчет модных-современных ciphers, в обход openssl я бы, кстати, был осторожен.)

Собственно, вам мало фееричного факапа с "roaming"?

Который дописать не дописали (и вообще до сих пор неясно, что это было и нахрена сдалось, а главное - кто с кем эту важную и нужную фичу обсуждал прежде чем тащить мусорный недоделанный код в релизные версии), а exploitable уязвимость, причем - в клиенте, где ее вообще не ждешь и никак не можешь от нее заранее защититься - вот она.

К сожалению, поляна загажена, Йлонен банкрот, другого sshd нет в помине.

Вот только нинада тут про божественный код от создателя ссш!
Я и оригинал смотрел на момент выхода в опенсорц, там косяков хватает, которые до сих пор в том же кейгене не вычистили.

При каком таком?

Ну если посмотреть на код виртуализатора, там как-то "не очень": в коротком куске кода аж три бага подряд, если не четыре, при том они позволяют виртуалке устраивать адские лулзы, пролезая через изоляцию от хоста, да еще аж в ядро.

У меня были мысли использовать опенок в микроисталяциях по принципу "только система, поставил и забыл". Но блин, нельзя же так.

не бывает надёжных систем, бывают плохо проаудиченные :)

Ну и зря. Весьма хорошо конфигурируется. PXE boot настраивается очень просто и можно сделать так, что у вас голая виртуальная машина пудет по PXE грузить инсталлятор, устанавливать OpenBSD с той разметкой диска, как вы хотите, с конфигурацией сетевых интерфейсов, hostname. Это весьма удобно бывает. Как раз таки для микроинсталляций она очень удобна и лаконична. Я бы вам рекомендовал попробовать, если есть время.

А уязвимости, если так досконально ковыряться, то они у всех есть. Просто, в последнее время, с негативом в сторону linux из-за их некоторых гениальных решений в разрез с сообществом, решили подзасрать репутацию OpenBSD. Что они NetBSD не ковыряют. Там тоже виртуализация есть. Судя по всему ноги у виртуализации на BSD системах ростут из одного места, так что это ещё нужно разбираться кому принадлежит награда за говнокод. Кстати! Тео де Радт очень сильно ругался по поводу виртуализации, когда его спрашивали, почему в OpenBSD нет, а потом вышла виртуализация на OpenBSD. Т.е. полагаю, они погнались за молодёжью и выдали, как и все очень сырую реализацию.

Когда в qemu находят уязвимости, что то вы не выключаете свои гипервизоры, хотя она в основу почти всех виртуализаторов входит, которые эмулируют другие архитектуры. Т.е. если в qemu уязвимость, это и KVM, и VirtualBox на помойку сразу же.

> Ну и зря. Весьма хорошо конфигурируется. PXE boot настраивается очень просто и можно сделать так, что у вас голая виртуальная машина пудет по PXE грузить инсталлятор,

кстати, вопрос. как запустить OpenBSD pxeboot в EFI?

Так с qemu все понятно. Не стоит же вопрос по безопасности: openbsd vs qemu. Просто информационное поле зашумлено такими вещами как: openbsd, безопасность, аудит, никакого спагетти-кода, академичность и все такое. За это как бы прощается техническое отставания от мейнстрима. А выходит так, что это всё бла-бла и реальность иная.

Да, всё верно. Бла-бла-бла... Проотвечались. В мусорку. (сарказм)

Обиделся, да? Ну извини.

Нет же! Не обиделся. Просто цепляясь к фразе безопасный и с нахождением дырки в каком то из компонентов, выводы вполне логичны ваши. Можно много оправданий найти. Но за слова нужно отвечать.

> Так с qemu все понятно. Не стоит же вопрос по безопасности: openbsd vs qemu. Просто информационное поле зашумлено такими вещами как: openbsd, безопасность, аудит, никакого спагетти-кода, академичность и все такое. За это как бы прощается техническое отставания от мейнстрима. А выходит так, что это всё бла-бла и реальность иная.

Тут как бы вот ещё какая мысль возникла. qemu тоже ставится с OpenBSD можно тоже притянуть уязвимости в qemu, как уязвимости в OpenBSD.

А отставание от мэйнстрима это заблуждение. Если по пакетикам брать, так в этом debian stable фору даст OpenBSD. А если вы о docker, виртуализациях и файловых системах, то тут вопрос скользкий. Можно сказать, этот проект не распаляется на всё подряд, а чётко выставляет приоритеты. В то время, как в сообществе linux одна технология обганяте другую, побивая костылём, и так и не доходит до вменяемого состояния, будуче побитой следующей. Или 100500 способов сделать одно и то же, это не преимущество.
Если мы возьмём кровавый энтерпрайз, то там вообще любят лачуги делать из говна мамонта. И тут уж точно OpenBSD легко вписывается в инфраструктуру.

Вот чё сейчас модно в VPN?... WireGuard?... А большей частью кровавый энтерпрайз сидит в лучшем случае на l2tp/ipsec, в худшем на PPTP. А точнее на том что предлагают MikrtoTik и Cisco, но так чтобы Windows из коробки мог с этим работать... А это L2ltp/ipsec или pptp... Хотя MS уже вырезала PPTP, но кто сказал, что кровавый энтерпрайз сидит на свежих форточках?...

Так что, когда говорят про отсталось мне особо хочется смеяться в лицо таким людям. Потому что в серьёзных масштабных проектах не используют последние веения, ибо это чревато печальными последствиями.

Давай про апликейшен. Хотя можно и про сеть, сетевые фичи ядра обоих систем сравнить. И так, приложения. Что есть в openbsd, чего нет в linux? Web? Почта (хотя с почтой прокололись, и не раз)?  Все поднимаемо на линуксах. Хрен с ним с интерпрайзом. Опустимся с небес на землю. В чем надо себя убедить, что бы поставить  openbsd вмето linux, хотя бы на 5-10 серверов для среднего интернет магазина (ну там, телефония, почта, веб, devel, cd/ci и т.п). А потом через полгода не смочь запилить задачу по поднятию какой-нить жаба-хрени именно на oracle jre.
Если коротко - все, что поднимается на openbsd, так же поднимается на linux. А вот наоборот - нет.
Киллер-фича безопасность? Ну вот уже нет. А в свете grsec,selinux тем более.

Так с этим и не поспоришь. Всё верно сказал. Но телефонию, почту, веб можно легко поднять на OpenBSD. Вот CI/CD это классные абривиатуры... (не заставляйте меня смеяться вам в лицо (отсыл, к предыдущему моему комментарию)) Но это больше концепция, подход, чем технологические стороны. Реализуемо и на OpenBSD. Что касается Java на OpenBSD, вот тут не знаю. Стандартную инфраструктуру обычной компании можно легко поднять на OepnBSD. Изыски... Ну, тут уж извините.

Вы сейчас пытаетесь сказать, зачем изучать OpenBSD, если Linux куда более распространён. С прагматичной точки зрения вы правы.

Надо ли пересаживаться на OpenBSD повально, заменяя ею всю инфраструктуру - нет конечно же. Есть ли недостатки у неё - конечно же есть.

Только опять же с вашим подходом, вы столкнётесь с ситуацией, когда конкретно ваш linux дистрибутив, будет не хорош, для решения вашей задачи, и вы возьмёте другой linux, пусть даже с дырами и недостатками, но решающий вашу проблему, а потом вас принудительно посадят на systemd и потребление самой минимальной конфигурации вашего дистрибутива возрастёт до 512МБ (может 256 быть, но это прям со скрипом). А когда вы расстроитесь, предложат вам альтернативой docker, дырявый как дуршлаг и ничего не могущий за рамками host системы. Потом вам предложат аркестрацию всего этого через кубернетис, вам расскажут, что сеть должна работать не так, как обычно, для всех этих 100500 докерконтейнеров, которым нужен свой ip, вам предложат воспользоваться ipv6, потом вас убедят, что на каждой системе должен быть правильно настроенный FireWall, даже если это ip-камера. Для манипуляции с сетевыми интерфейсам вам предложат пересесть с ifconfig на iptools2, потом вкорячат NetworkManager даже на сервера, и скажут, что сейчас для простоты лучше использовать его, но только там сейчас биджинг не возможен и часть манипуляций с интерфейсами вам предётся делать по старинке, для настройки FireWall вам предложат пересесть с iptables на firewalld, потом неожиданно передумают и вернут в основную ветку дистрибутива iptables, а потом скажут, что сейчас вообще модно пакетики обрабатывать без ядра в userspace с компиляцией правил в байткод и впихнут вам BPF, который между прочим из NetBSD приплыл. И вот пока пока вы всей этой хренью занимаетесь выигрываете в бенчмарках жалкие процентики, изучаете массу ненужного, что было рождено, чтобы умереть через пару лет. Пользователи в BSD системх продолжают настраивать сеть через ifconfig, описывать старт сервисов в своём немодном скучном rc.conf, использовать тот firewall, который им нравится, без принуждения со стороны заднеприводных модных программистов. Скукатища. А потом ещё этот ZFS никому не нужный, выпустят под неправильной лицензией и пользователи BSD систем без каких либо проблем смогут им наслождаться на уровне ядра системы, в то время, как в linux сообществе будут убивать человекочасы-годы, чтобы придумать, как схитрить, чтобы не нарушить лицензионный бред, которому им приходится придерживаться, чтобы не проотвечаться. Ведь тогда же они будут беспринципные люди, если не соблюдают тот уговор, который сами написали.

Резюмируя предыдущий абзац, я наталкиваю вас на мысль, что технологически рост не велик в общем, есть масса велосипедостроения, которое пытаются охватить linux пользователи, в то время, как решение основных задач уже давно придумано и хорошо описано. А все эти ваши CI, CD, DevOps - киркоровы от мира IT.

Такие технологии, как CARP, OpenSSH пришли из BSD. И вот тут хочется вспомнить высказывание: "Ты можешь построить хоть тысячу самых технологичных, самых больших мостов, но если ты хотя бы один раз возлежал на ложе с мужчиной (будучи сам мужчиной), то запомнят тебя ни как великого мостостроителя". - Продолжайте собирать о людях грязь, и нести это в памяти всю свою жизнь.

> В чем надо себя убедить, что бы
> поставить  openbsd вмето linux, хотя бы на 5-10 серверов для
> среднего интернет магазина (ну там, телефония, почта, веб, devel, cd/ci и
> т.п). А потом через полгода не смочь запилить задачу по поднятию
> какой-нить жаба-хрени именно на oracle jre.

Вот на это отдельно по вопросу отвечу. Убеждение само приходит, даже не нужно стараться, когда задалбывает котовасия в linux. Когда ты уже отладил работу своих сервисов, придумал, как раскатывать конфигурации, как группой управлять. А потом такой поттеринг из засады сзади выскакивает и на тебе! SystemD по самые гланды!... А потом ещё и docker начинают везде пихать. И ты такой - Ну, вас в ... Пойду поищу, что-то постабильней, чтобы не ломалось с обновлениями по факту уже случившегося события, чтобы не думать зачем мне NetworkManager на сервере, и почему он может не всё, если он для конфигурации сети.

Ну, это лично моя реакция. Я признаю, что тут я смалодушничал, надо было проявить стойкость и освоить всё это безобразие, переделать всю инфраструктуру. Но в ж... Лучше пойду в программисты, буду писать говнокод на java для энтерпрайза, а с linux, docker, kebernetis, пусть молодёжь мучается, мне фиалетово.

А дома только BSD только суровый консервативный софт покрывшийся мхом.

Не убедительно. Сопровождая xBSD, тоже надо и с дебагером сидеть и в багзиле.

> выскакивает и на тебе! SystemD по самые гланды!

Опять эмоции. Если в релизе небыло systemd, то его не будет до EOL. Не?

> Только опять же с вашим подходом, вы столкнётесь с ситуацией, когда конкретно ваш linux дистрибутив, будет не хорош, для решения вашей задачи, и вы возьмёте другой linux,

Вероятность, что ваш xBSD будет не хорош для решения ващей задачи и вы возьмёте linux, близка к единице. Привет.

Я вообще к чему. Я к тому, что мое желание ипользовать openbsd куда-то пропало, хотя я тоже поддавался эмоциям на тему "openbsd  - оно же такая особенная". Мне вот было интересно ставить опенка при принципу поставил и забыл, но какой кайф получать инфу, что твои инсталяции 2-5ти летней давность вдруг оказались дырявыми и надо либо накатывать обновы либо самому патчить. А король-то голый. Сие печаль.

В любом другом дистрибутиве не так?

> что твои инсталяции 2-5ти летней давность вдруг оказались дырявыми и надо либо накатывать обновы либо самому патчить.

"TTL" релиза декларирован, никто не обещал какой-либо особенной поддержки после его истечения.
Как верно заметили с любым Linux-дистрибутивом ситуация аналогичная.

Помню как страдал эксплуатируя Debian с каким-то 2.6*, так как возможность обновления блокировалась отсутствием драйвера синхронного адаптера Е1 для свежих версий ядра.

Впрочем и сейчас есть доступ к такому хосту, там уже от стокового Debian, скоро только /etc и /var останутся. :)

Суть в том, что я был готов забить на TTL с пониманием того, что openbsd не пробиваемый. С учетом последних новостей, с тем же успехом можно поставить линукс, к тому же обвязав его селиниуском.

> Суть в том, что я был готов забить на TTL с пониманием того, что openbsd не пробиваемый.

Я из таких решений только MS DOS 3.х видел, без какого-либо коннективити вовсе. ;)

ЕМНИП видел под ДОС tcp стек) И кстати, какие-то кассы ( ну там, чеки пробивать) вроде на ДОСе по прежнему.

> Вероятность, что ваш xBSD будет не хорош для решения вашей задачи и вы возьмёте linux, близка к единице. Привет.

Как вы посчитали?

Ставиться по PXE с нужной конфигурацией умеет любой приличный линукс.

> гениальных решений в разрез с сообществом, решили подзасрать репутацию OpenBSD.

Ну вообще, козырять секурити а потом обнаружить что баг отрепорченый 5 лет назад не починен портит репутацию независимо от того решил кто-то ее подзасрать или нет. Гамнокод с примерно 4 багами в мизерном фрагменте, позволяющий юзерской виртуалке патчить нахрапом аж сразу кернельную память, кстати, тоже.

не "отрепорченный" (хоть бы никто из НИИ им. Виноградова сюда никто не заходил, удар же хватить может от такого издевательства над языком) пять лет назад, а появившийся. Зачем врать-то на ровном месте? Чтобы вам потом меньше верили? Хитрый ход.

> Гамнокод с примерно 4 багами в мизерном фрагменте,

Экраном выше было 3, а в соседней теме 2, или примерно у вас это между 0 и 1000?. :D

> Экраном выше было 3, а в соседней теме 2, или примерно у
> вас это между 0 и 1000?. :D

Maxime в оригинале видит от 3 до 4 проблем в том коде. Так что 2 - это кто-то поскромничал.

>Судя по всему ноги у виртуализации на BSD

Что не так с bhyve?
Недавно погонял и был впечатлен, думал пилиться еще лет 10 будет, а тут уже для моих целей все готово и можно забыть про виртаулбокс.

> Проблема является следствием неполного устранения проблем, озвученных в процессе аудита, проведённого Qualys в 2015 году.

ППЦ.

Всю ночь гребли, а лодку отвязать забыли...

> Всю ночь гребли, а лодку отвязать забыли...

да тут пять лет гребут, не приходя в сознание, похоже - а лодка вообще на берегу лежит, да и то кверху дном.

Ну чото с opensmtpd совсем хреново получилось.

они что, не проверяют длину строки О_о?

Не нужно проверять длину строки, потому что это подразумевает strlen() над данными полученными извне, что легко даст результаты ещё хуже.
В данном случае нужно оперировать буферами, и размерами как буферов так и использованной в них части, потому что информация по наполнению буферов возращается теми же recv()/read() и ей можно доверять.

Как насчёт strnlen?

не думал что напишу такое, но Аноним дело говорит! а за strlen надо по рукам бить.

> Как насчёт strnlen?

в котором n = размер буфера/возвращаемое значение recv (что вообще-то, по-моему и подразумевается под "… оперировать буферами, и размерами как …") ?

Зачем!?
Если что, оно примерно эквивалентно (memchr(buf, 0x00, buf_size) - buf).
Если ты и так знаешь размер буфера и сколько там использовано то к чему это бесполезное действие?

> Не нужно проверять длину строки

А что если атакуюший строку в 20 гигабайт накидает? Или такие подарки ловятся в другом месте?

Благодаря наследству, чтобы узнать длину 0-terminated строки, надо сначала ее всю вычитать (в память, например,) и там может быть и 4TB. :)

> Благодаря наследству, чтобы узнать длину 0-terminated строки, надо сначала ее всю вычитать
> (в память, например,) и там может быть и 4TB. :)

Ну как бы доверять тому что декларирует ремота мы всяко не можем, наследство там или уж нет. Есть целый отдельный класс багов когда задекларено одно, а прислано другое, и совсем не факт что это лучше, потому что позволяет поприкалываться.

Однако получение данных вообще должно бы в какой-то момент рещить что слишком дофига для всего лишь строки, чтоли.

> Однако получение данных вообще должно бы в какой-то момент рещить что слишком дофига для всего
> лишь строки, чтоли.

и добавить в конец (пооверрайдив последний байт буфера) \0, что решает проблемы с бестолковым использованием strlen.

Кстати, вспоминая опять же openssh - _одна_ off-by-one error, за все время. _без_ использования strn*, которые могли запросто отсутствовать на половине систем, поддерживавшихся ssh1.

(и чудовищная с remote root в syslog, но это претензия к автору syslog() все же. Никто тогда не ожидал этой подставы, вляпались все, кроме использовавших sprintf с померянным буфером по каким-то вовсе другим соображениям)

не проблема совсем. вызову read передается дисриптор, указатель на буфер, размер элемента и максимальное кол-во элементов, которые можно поместить в буфер. если дескриптор готов вернуть больше, то read прочитает ровно по размеру буфера. а дальше приложение уже должно само решать - посылать такого толстого клиента нафиг или расширять буфер чтобы прочитать новые данные. и так после каждой операции чтения.

> нафиг или расширять буфер чтобы прочитать новые данные. и так после
> каждой операции чтения.

Вот мне и интересно что они сделали. Надуть именно read можно только если програмер совсем уж лох, а вот чего со строками делают в этом плане...

Куда накидает!?
На приёме обычно примерно так (чуть упрощённо):
received = 0;
for (;received < buf_size;) {
  rv = recv(skt, (buf + received), (buf_size - received));
  received += rv;
}

ну вот больше buf_size у нормальных адекватных людей не примется данных.
А неадекваты конечно могут юзать strlen() и дальше на таких данных.
Я вообще не представляю куда тут strlen() можно пристроить будучи в адеквате.

> они что, не проверяют длину строки О_о?

А как тогда делают:
>> спользуемый для определения текста, устанавливается на байт, следующий за символом '\0'

?
Скорее "логическая ошибка" при обработке входных данных.

У них просто хреновый парсер. Делают неявные предположения, не обрабатывают всех возможностей по ходу перебора байт буфера от первого и до терминирующего. Надеются, что входящий набор байтов будет таким, и никаким другим (и какой в тестах накидан). Типичная ошибка ничинающих.

>  Надеются, что входящий набор байтов будет таким, и никаким другим (и какой  в тестах накидан). Типичная ошибка ничинающих.

*SCNR*
https://www.opennet.dev/opennews/art.shtml?num=45244
> Процесс PID 1 зависает на системном вызове pause() при поступлении в сокет уведомлений systemd сообщения нулевой длины
> Атака сводится к выполнению команды
> NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""

А в systemd полно не просто начинающих, а вообще не начавших.

Мда уж.

Qualys - респект.

> Мда уж.

Ну так себе, ну. Сейчас тред посетит мр. пох. и сообщит, что он же говорил!
А особенно обидно, что и возразить нечего. :D

> Qualys - респект.

Респектовать не только им надо. Ты читал как несколько дней назад профи из NetBSD - Maxime Villard выпорол хворостиной опенбздшников за бестолковый идиотизм?

https://marc.info/?l=openbsd-tech&m=158176939604512&w=2
https://marc.info/?l=openbsd-tech&m=158237030723610&w=2

Вам вообще (юзерам OpenBSD) не зазорно пользоваться такой бестлковой ос, которую, судя по всему, пишут не совсем грамотные программисты? Это ж чистой воды неуловимые джо, которые к тому же не могут с первого раза баги прикрывать или не догоняют техническую суть (как в случае с гипервизором vmm).

Я не хэйтер, но доверия к такой ОС нет никакого, честно говоря. Какая-нибудь центос и то будет защищённее, так как на базе рхела разрабатывается, а там аудиты не пару раз в год, а каждый месяц  и целая армия тестеров - кто на зарплате, а кто и по доброте душевной.

> Какая-нибудь центос и то будет защищённее, так как на базе рхела разрабатывается, а там аудиты не пару раз в год, а каждый месяц  и целая армия тестеров - кто на зарплате, а кто и по доброте душевной.

И в ней на порядок больше находят серьезных проблем уже после релиза.

> И в ней на порядок больше находят серьезных проблем уже после релиза.

Не спорю. И они исправляются. Но если всю эту армию и возможности натравить на OpenBSD картина будет ещё более удручающей. Вот и получается, что пользователи OpenBSD живут по принципу неуловимых Джо. Это не самая безопасная ОС, это ОС которую мало изучают. А если и изучают, то фэйспалм на фэйспалме.

> Не спорю. И они исправляются

Ну так и разработчики OpenBSD исправляются. Це факт. Не бачу рiзницы.

> Но если всю эту армию и возможности натравить на OpenBSD картина будет ещё более удручающей.

А это уже догадки.

> Ну так и разработчики OpenBSD исправляются

Согласно техническим простыням от Макса из нетки - разработчики OpenBSD не исправляются, а наоборот - деградируют.

> А это уже догадки.

Вот только убогое качество кода и примитивные ошибки в OpenBSD - это уже тенденция. Так что "догадка", как вы говорите, об удручающей _возможной_ картине при увеличении аудиторов, совсем уже и не догадка, а аналитический вывод.

> Не бачу рiзницы

Значит спорить не о чем. Пользуйтесь OpenBSD на здоровье. Ведь это самая безопасная ось. Ку-ка-ре-ку онли ремоут хоулз ин э хэк оф а лоyг тайм Ку-ка-ре-ку.

>> И в ней на порядок больше находят серьезных проблем уже после релиза.
> Не спорю. И они исправляются. Но если всю эту армию и возможности
> натравить на OpenBSD картина будет ещё более удручающей. Вот и получается,
> что пользователи OpenBSD живут по принципу неуловимых Джо. Это не самая
> безопасная ОС, это ОС которую мало изучают. А если и изучают,
> то фэйспалм на фэйспалме.

Слушай, ты сейчас только по одному инциденту с виртуализацией OpenBSD'шной говоришь, или прям у тебя много примеров говна? То что вам красная шапка вогнала systemd принудительно, я молчу. То что вам docker корявый в прод убедили поставить, вот это меня волнует. Целую экосистему для контейнеров придумали, где сеть не совсем сеть, файловая система не совсем файловая система, изоляция не до конца изоляция. И это как бы неуловимых джо с красными шляпами не волнует. Виртуализация же в OpenBSD это зародыш эдакий, на который, судя по всему и них нет ресурсов. Сам Тео говорил про виртуализацию, как про попытку сделать больше дырок на и так не идеальных хостовых системах. И это про любую виртуализацию можно сказать. Однако этого было мало, и решили все силы бросить на контейнеры и сделать ещё одну дырявую сестему. А потом ещё сказали что это высшее искусство Dev (тьфу его) Ops. Вот именно так это и выглядит, как звучит. Сначала что-то там развивают, а потом Опс! Что мы наделали?!

С почтовым то сервером они муху дали. Вещь нужная, её бы можно было и повнимательней писать. Но вот за виртуализацию чихвостить... Не за то вы взялись. У linux сообщества есть чему устыдиться в этом вопросе. Так много времени и сил потратить в некуда, наловить с этим кучу говна и остаться всё в той же лужи с куда более огромным техническим долгом. То, что у linux больше сообщество, это позволяет ему производить больше говнокода. Шедевры вроде lvm редко выскакивают. Даже Postfix, наверное больше ориентирован на BSD, чем на linux.

Не просто так же OpenBSD переписывает утилиты на свой лад, занимаясь откровенным велосипедизмом. Просто на базе того, что есть, не реально удержать хоть, какую-то безопасность.

Из того, что я у себя запускаю в виртуалках, всё крутится на OpenBSD, как раз именно по тому, что это поднимается в разы легче, и обслуживается весьма ожидаемо. Чего не могу сказать о linux, в котором концепция - Посотри, какую класную весч я сделал, а что с ней делать, и как её вписывать в свою экосистему, подумай сам. Это opensource, мне дальше лень думать.

А такие, как красношляпые, умудряются делать это ещё и за деньги. Т.е. мы тут вы...ли, но дальше вы сами. Это opensource, и если поттеринг сказал, что это не баг а фича, то ты должен это принять с покорностью. Тем более, куда ты "неуч денешься"? Не на OpenBSD же пойдёшь? Поэтому терпи.

Злорадствовать не буду, но опять как и после случая нахождения уязвимости в postfix - хотел бы спросить:

Не стыдно ли тем хейтерам что с пеной у рта кричали "ре*ето"" в адрес exim ?

Так "ре*ето" же. Давно не новость.

> Так "ре*ето" же. Давно не новость.

Не более "ре*ето" чем любые другие МТА.

А хейтят именно exim массово.

Exim конечно очень удобен, тем что конфигурабилен, по этому параметру он лучше postfix.
Но с уязвимостями и работой под нагрузкой у него похуже.
Ну чаще и страшнее дырки.
Хотя дырки есть у всех.
А про хейтить, Вы не застали времена sendmail. Вот тогда хейтили и заслужено.
Ну так потому он и почти вымер (ну и конфиг у него был, дай бог больше не видеть).
А при сравнении всего 2 postfix и exim. Нагрузка не всех интересует остается хвалить за удобство конфигурирования и ругать за безопасность.

>Вы не застали времена sendmail

1.

Я Ленина видел :) (На PDP-11/70 на фортране зачёт сдавал :)  )

2.

Согласен в остальном - всё правильно пишите - просто за exim мне обидно стало - ведь 90+% его хейтящих к профе постмастер и близко отношения не имеют.

Хейтят за то, что фанбои на очердную дырку отвечаю "за-то вexim есть такая уникальная  фича...".

> Хейтят за то, что фанбои на очердную дырку отвечаю "за-то вexim есть
> такая уникальная  фича...".

Ну то фанбои - вменяемые люди накатывают обновление и продожают пользоваться exim-ом дальше.

Поэтому, если нужно, что бы все же безопасно, то postfix. Нет жизни без фич - то exim. Только вот даже я склонялся к opensmtpd, что бы без фич но поставил и забыл. Но хрен.

Чем постфикс не подходит, для поставил и забыл?

>>Вы не застали времена sendmail
> Я Ленина видел :) (На PDP-11/70 на фортране зачёт сдавал :)  

Внутривенно?
(IV, хаха)

> Не более "ре*ето" чем любые другие МТА.

Более. И поверхность атаки менее разграничена.

Про уязвимость в postfix давайте подробнее, там за всю историю только какие-то несущественные мелочи были. Серьёзных уязвимостей пока не раскрывали.

Нужные люди ещё не используют, с exim не могут пересадить

В 2011 была как раз таки "критическая" уязвимость

как знал, всегда opensmtpd отключаю :) хотя данную уязвимость у меня и не поэксплуатируешь...

В 2011 была как раз таки "критическая" уязвимость.

а нельзя сразу всё нааудитить и пачкой выложитЬ, а то каждый день - новости :)

> а нельзя сразу всё нааудитить и пачкой выложитЬ, а то каждый день - новости :)

Можно, я разрешаю - аудить! И чтоб завтра всей пачкой выложил.

А кстати, наловили ли подобных вещей по пресловутому qmail? Из номера 2 он превратился в шум, но ведь не из-за этого?

qmail никогда не был безопасным. Могу обосновать. Мне уже скоро 20 лет назад достался по наследству сервер с этим поделием.
Он совершенно безопасен в базе, но только по тому что не умеет ничего.
Кстати вот он был бы хорошим кандидатом на локальный почтовый сервер по умолчанию.
Только письма от локальных систем руту слать, ну или админу на нормальную почту, через свой полноценный сервер.
А чтобы сделать с этим безобразием хоть что-то реальное на шлюзе, ну вообще хоть что-то надо его патчить.
И вот тут начинается треш. Потому что никто те патчи на безопасность уже не проверял и на их сочетание между собой тоже. Нет Вы конечно можете все сами сделать, но только тогда надо форкать qmail и начинать пилить полноценный почтовый сервер.
А так вся безопасность в том что никто не знает что Вы там и как накомпиляли и если нет задачи сломать именно Вас, то ни одна бот система уязвимость в Вашем сервере просто по версии почтового сервера не найдет.
в общем он минималистичный, пригодный только для самых простых конфигураций и в таком состоянии вполне хорош.
Но если Вам вдруг завтра понадобится выйти на полшага за пределы минималистичной конфигурации, то можете начинать настраивать postfix или exim. патчить это безобразие категорически не советую.
Это менее безопасно и ни разу не быстрее чем поставить и настроить что-то другое.

> qmail никогда не был безопасным. Могу обосновать. Мне уже скоро 20 лет

...
> А чтобы сделать с этим безобразием хоть что-то реальное на шлюзе, ну
> вообще хоть что-то надо его патчить.
> И вот тут начинается треш. Потому что никто те патчи на безопасность
> уже не проверял и на их сочетание между собой тоже. Нет

Благодарю, но я это знаю, я когда-то работал с qmail, и именно в нелокальной конфигурации.
Не красная ковровая дорожка, но и не шахта и забой )).

Меня интересует -- так поймал кто-нибудь что-нибудь в qmail?
Вот в djbdns вроде бы отловили 1 или 2 проблемы. А в qmail? Так-то в поисках не видно.

Там вроде и ловить негде. Да и не ловит никто, не интересно.

> Там вроде и ловить негде. Да и не ловит никто, не интересно.

А когда был номер 2 после sendmail, то было-таки поинтереснее?

> Он совершенно безопасен в базе, но только по тому что не умеет ничего.

о, смотрите-ка - хоть один это понял.
Автор гордо заявлял что это проблема - не его проблема, как и то, к чему приводит попытка эксплуатации его поделки в реальных условиях - "а это не мои патчи, я за них не отвечаю". Даром что без них она бесполезна абсолютно.

Когда-то у меня именно qmail занимал в логах второе место после поцфиксов по количеству беспроверочно прорелееного спама - потому что ставившие его васяны обламывались о выключенный релеинг, получали по заду за то что сломали всю почту и включали - ну а чо, оно же суперсикьюрна-супирсикьюрна. Голову при этом - не включали, она у них едой занята.

Было его все же поменьше, но в основном потому, что поцфикс везде уже был изкоробки, а qmail еще где-то взять надо, про это догадывался только каждый второй васян.

P.S. а зачем, кстати, было 20 лет страдать-то?

> Когда-то у меня именно qmail занимал в логах второе место после поцфиксов
> по количеству беспроверочно прорелееного спама - потому что ставившие его васяны

Ну так его популярность пришлась на годы, когда спам уже был, а толковых антиспамовых систем ещё не было.

> Ну так его популярность пришлась на годы, когда спам уже был, а
> толковых антиспамовых систем ещё не было.

толковых не было, но релеить 0/0 все же было уже не принято - соответствующий патч к сендмэйлу - 97й, вроде, год (или 96й?), штатные механизмы на его основе - чуть позже.

Популярность среди васянов пришлась на 99-2005 - когда все уже было, но васяны с qmail бодро релеили любой мусор.
Васяны с поцфикс отставали, поскольку его э... особенность не позволяет релеить любой, даже в сочетании с багом (который если и исправили, то сильно позже).

Сейчас они вырвались далеко вперед - qmail и поставить непросто, и "особенность" в свете массхостингов перестала быть невинной, даже без бага, который на массхостингах не проявится.

>> Ну так его популярность пришлась на годы, когда спам уже был, а
>> толковых антиспамовых систем ещё не было.
> толковых не было, но релеить 0/0 все же было уже не принято

[...]
> Популярность среди васянов пришлась на 99-2005 - когда все уже было, но
> васяны с qmail бодро релеили любой мусор.

А в чём там было дело? Я даже в 90-х не видел в наших далеко-не-столичных краях систем, релеящих для всех. Только читал о них, однажды, мол, в Америке.

>qmail никогда не был безопасным. Могу обосновать

Необоснованное и слишком категоричное заявление!

Для qmail действительно требовался один патч - QMAILQUEUE (он всего лишь изменял имя вызываемого файла очереди, например, на qmail-queue.real) Уязвимость добавить таким патчем не реально!

После этого с qmail можно было делать что угодно: smtp авторизация, антивирусная проверка, проверка наличия получателя через LDAP/AD, greylist, etc. И это все в то время, когда postfix еще не планировался, а exim был еще Smail-3

> А кстати, наловили ли подобных вещей по пресловутому qmail? Из номера 2

DJB таки дотошный типок, найти в его коде баг - редкость.

> он превратился в шум, но ведь не из-за этого?

Абсолютно. DJB просто подзабил на развитие своих проектов, не став обмазывать их новомодными гов^W фичами. Это сделало его проекты достаточно маргинальными.

К сожалению, это весьма фундаментальный tradeoff софтостроения: если вы хотите стабильный и предсказуемый софт без багов (в том числе и багов приводящих к проблемам безопасности) - софт должен быть как можно более простым.

> софт должен быть как можно более простым

Ну вот пример из топика в частности, и OpenBSD в целом ярко, иллюстрирует, тот факт, что безопасность через ограниченность функций тоже не работает.

ЗАЛИЛИ. Опять вебмакаки портят код сишникам срывами буфера. Коммит с дырой был сделан по приказу лично Леннарта.

Позвольте, но где aslr? Где неисполнимая память?

там уязвимости из-за того, что шел-скрипты можно исполнять, причём здесь неисполняемая память

Да, я уже посмотрел фикс, признаю, был неправ. Проблема с буфером мелкая и нужна только для того, чтобы перезапустить опенсмтпд. Основная проблема в exec() без абсолютных путей.

Opensmtpd? Это который используется на 0.05% серверов? Да это же Тот Самый Неуловимый Джо!

Хмм, хмм... Кто-то капитально взялся за опёнка? Если судить по последним местным известиям :). Кстати, а как оно на PowerMac-е живёт? :D

это аудит. он достаточно часто проходит.

> это аудит. он достаточно часто проходит.

Я бы так не сказал, ибо тут есть небольшая тонкость. Тут никогда не было _ПОСТОЯННЫХ_ аудитов. Всё происходит довольно _эпизодически_. Просто Qualys в последнее относительно недавнее время занялось этим вопросом более плотно. Так или иначе это плюс, так как реальное положение дел далеко от совершенства и в глазах публики OpenBSD уже не асоциируется с самой безопасной ОС. Безопасность в этой ОС, скажем так, самая обыкновенная, типовая и ошибки довольно типичны.

Постоянный аудит - это вам к операционным системам типа RHEL, где сидит целая армия на зарплате + тестеры, кто по доброте душевней сам этим занимается.

Странно, что ни одного переписывателя на раст/го/питон. Как раз от этой ошибки безопасный язык бы защитил.

если ещё и в базовую систему rust/go/python тащить... нее. можно на perl переписать, он в базовой системе есть :)

Вы опоздали - на awk netch@ когда-то написал. (если кто вдруг разыщет гуглем - учтите, в первой версии вроде RCE. Но он потом поправил это место.)

Надо срочно завести проект на гитхабе, ой, простите, на гитлабе, пока другие не сперли идею!
У меня уже и CoC.md готов!

а вообще, как только песенки перестали выпускать, так всякая фигня начала твориться. верните песенки!

нам песня строить и жить и компилить помогает...

она как друг нас зовёт и ведёт к торжеству раста

> она как друг нас зовёт и ведёт к торжеству раста

А потом смузихлебам вгрузят какой-нибудь крап прямо в репу - и они дружно подавятся смузи.

> А потом смузихлебам вгрузят какой-нибудь крап прямо в репу - и они

память о leftpad намекает, что можно даже не вгружать, а выгрузить уже сто лет назад вгруженный - результат немного фееричен, и прикопаться к автору не получится.

Объявляю 2020 годом похорон мифа об особенной безопасности OpenBSD

Если что, разработчики OpenBSD никогда не называли свою ОС _самой_ безопасной, это само по себе обывательский миф. Ну, вроде того, что чем больше мегапикселей у камеры, тем она лучше.

> Если что, разработчики OpenBSD никогда не называли свою ОС _самой_ безопасной, это

доо, доо, и херни про "ни одной уязвимости за n+1 лет" (для невоткнутой в розетку) не несли, и fud про "тотальный code review" не было, и прочих баек.

Мы ж все вчера родились, и никогда писем Тео не читали.

Возможно, конечно, что в прошлом таких громких факапов и не было (а не не нашли, потому что никому не был интересен неуловимый джо), а нынче бароны постарели. Но это прошлое - очень далекое прошлое, больше десяти лет назад уж точно.

>> Если что, разработчики OpenBSD никогда не называли свою ОС _самой_ безопасной, это
> доо, доо, и херни про "ни одной уязвимости за n+1 лет" (для невоткнутой в розетку) не несли, и fud про "тотальный code review" не было, и прочих баек.

Ты подменяешь понятия -- "Самой самой" != "Only two remote holes in the default install, in a heck of a long time!"

Что касается остальной части твоего пассажа, так это глупый фуд, видимо обусловленный личной неприязнью. Ты ведь понимаешь, что найдись сейчас спонсоры аудита кода от единственно-правильного сообщества, найдут и не такое.

>>> Если что, разработчики OpenBSD никогда не называли свою ОС _самой_ безопасной, это
>> доо, доо, и херни про "ни одной уязвимости за n+1 лет" (для невоткнутой в розетку) не несли, и fud про "тотальный code review" не было, и прочих баек.
> Ты подменяешь понятия -- "Самой самой" != "Only two remote holes in

нет, я говорю что fud и пропаганда, не подтвержденная ни качеством кода, ни аудитом - были.
И первое время - имели успех. Чем и вызвана моя личная неприязнь, я потратил время на то, что даже в защитных перчатках не надо было трогать руками. Потом началось виляние ужом про, сперва, "default install" (главное  - в розетку не втыкать) а потом и про "only two" (найденных, причем третьими лицами)

> личной неприязнью. Ты ведь понимаешь, что найдись сейчас спонсоры аудита кода
> от единственно-правильного сообщества, найдут и не такое.

Такого п-ца - навряд ли найдут, потому что спонсоры находились, и неоднократно.
Это ж только неуловимый джо нахрен никому не нужен. А тут люди бабки свои доверяют этим поделкам.

Даже дыры в exim (вызванные не только тем что до кода дорвались, похоже, студенты недоучки, но и сложностью решаемых этим кодом задач, к которым open даже близко не стоял) не были такими позорными - надо было запилить весьма странный конфиг, чтобы от них пострадать, и можно было - запилить куда менее странный с типовыми для юнис-систем методами изоляции (хотя и не принятыми по умолчанию).

> нет, я говорю что fud и пропаганда, не подтвержденная ни качеством кода,
> ни аудитом - были.

Ты преувеличиваешь, мне жалко времени на строительство ретроспективы, но там и аудиты были и много чего.

> И первое время - имели успех. Чем и вызвана моя личная неприязнь,

Давай резюмируем, мне честно, без стёба жаль потраченного тобой времени, но никаких обещаний, кроме скромных утверждений (мы в соседнем топике так и не пришли к единому мнению была пр/реклама или нет) никто не давал и собственную печень в подтверждение не закладывал.

>> личной неприязнью. Ты ведь понимаешь, что найдись сейчас спонсоры аудита кода
>> от единственно-правильного сообщества, найдут и не такое.
> Такого п-ца - навряд ли найдут, потому что спонсоры находились, и неоднократно.

Какие продукты ты сейчас подразумеваешь?

> Это ж только неуловимый джо нахрен никому не нужен. А тут люди бабки свои доверяют этим поделкам.

Люди в основной своей массе слишком доверчивы. В противном случае МММы бы дохли еще на старте.

> Даже дыры в exim (вызванные не только тем что до кода дорвались,
> похоже, студенты недоучки, но и сложностью решаемых этим кодом задач, к
> которым open даже близко не стоял)

Вот это и называется двойными стандартами на мой взгляд. Т.е. exim со своими студентами - OK, а OpenBSD уже фу-фу-фу. Это нечестно, не находишь?

Что-то мне сейчас не приходит в голову задач решаемых exim, но недоступных для OpenSMTPd.

> OpenBSD никогда не называли свою ОС _самой_ безопасной
> это само по себе обывательский миф

Если прикапываться к словам, то - да, они никогда не называли себя самыми безопасными.
Но, тем не менее, они сами многое сделали для создания этого мифа.

Хорошо, что миф разрушен.

> Хорошо, что миф разрушен.

С некоторых пор считаю, что русскому хорошо, то немцу смерть. Утрировано, и естественно в частностях.
Внимание! А теперь вопрос. Кому "Хорошо, что миф разрушен."?

> Объявляю 2020 годом похорон мифа об особенной безопасности OpenBSD

Можно подумать, её безопасность ранее привлекала миллионы пользователей по всей планете. Да и сейчас не убавится. Большинство пионеров, запускающих OpenBSD, настраивает в нём Postfix, если настраивает вообще почтовый сервер. А знаете почему? Так же как и веб-сервер, скорей всего nginx будет на нём настраиваться. А знаете почему?

Потому что, любой пионер понимает, что если завтра выстрелит, какая-то более крутая операционная система, да тот же docker, его работодателю приспичет, то Postfix там скорей всего очень даже будет актуален, и специалиста на Postfix найти будет проще. А OpenSMTPD поставить в прод, потому что ты впечатлён OpenBSD, ну это как бы совсем по детски. Начальство тебе точно спасибо за это не скажет. Особенно если ты назовёшься DevOps'ом, попросишь зарплату в три раза больше и свалишь от них не оставив ни одной записочки, как это OpenSMTPD работает. А Postfix вполне заслужено популярен, стабилен. Ну хрен, что он костыльно извращённый, не монолит, за то прочтный, КАК СКАЛА! И любой школьник его сможет настроить по 100500 инструкциям в интернете на хабре, да даже на опеннете сможет найти инструкцию по нём и сделать кровавый энтерпрайз счастливым.

И OpenBSD хорошо известный в узких кругах по прежнему будет прекрасно работать на том же уровне, что и раньше, и ни кто не станет переделывать всю инфраструктуру. Потому как дыр везде хватает.

У меня только один вопрос. Почему хоронить его пытаются те, кто с ним никоим образом не связывал свою жизнь?

> Почему хоронить его пытаются те, кто с ним никоим образом не связывал свою жизнь?

Вы путаете похороны мифа с похоронами тела...
А так да - в сектах не состою.

А! прошу прощения. Тогда миф похоронили. Накатим по SMTPD?! ;)

> У меня только один вопрос. Почему хоронить его пытаются те, кто с ним никоим образом не связывал свою жизнь?

Отличный вопрос. Похоже большая часть бойцов систему даже не устанавливали!

ASAP - as secure as possible

$ apt show opensmtpd
........................
Description: secure, reliable, lean, and easy-to configure SMTP server
The OpenSMTPD server seeks to be
  * as secure as possible, and uses privilege separation to mitigate
    possible security bugs
........................

> Примечательно, что в Fedora 31 уязвимость позволяет сразу получить
> привилегии группы root, так как процесс smtpctl снабжён флагом setgid
> root, вместо setgid smtpq. Получив доступ к группе root можно
> перезаписать содержимое /var/lib/sss/mc/passwd и получить полный
> root-доступ в системе.

Чуваки просто не могут пользоваться обновлениями. Уже опровергли:

> Last-minute note: on February 9, 2020, opensmtpd-6.6.2p1-1.fc31 was
> released and correctly made smtpctl set-group-ID smtpq, instead of
> set-group-ID root.

https://www.qualys.com/2020/02/24/cve-2020-8793/local-inform...

Всё куда "веселее", к сожалению:

>[оверквотинг удален]
>>
>> https://bodhi.fedoraproject.org/updates/?packages=opensmtpd
>
> I have edited the update and flagged it as security.
>
> However, without feedback from community testing (karma), this update
> cannot be pushed at this time.
>
> The package also failed to build on Fedora 32 and 33/rawhide due to C
> conformance issues, so there are no updates available there.

(из oss-security)

Ничего там особенного нет, кроме самого факта уязвимости в апстриме (я мейнтейнер пакета opensmtpd).
Поставили флаг "security", но кармы по апдейту никто не добавил — это частый случай при апдейтах.
Фейл билда под F32/F33 — это печально, конечно, но учитывая, что релизов этих в природе ещё нет — проблема не такая уж большая.
Впрочем, это уже пофикшено и апдейты в этих ветках собраны.
И в целом, даже без кармы (никто не проверял апдейт) пакеты с апдейтами заедут в F30-33 и EPEL8 в ближайшие дни, по истечению времени нахождения в testing.

https://www.openwall.com/lists/oss-security/2020/02/26/1
exploit embargo lifted

Поставил OpenSMTPD, сложил туда все свои «яйца». Ломайте меня полностью!
Теперь можно спать спокойно.